Lokad ist in erster Linie ein Supply-Chain-Spezialist, und unser Hauptziel ist es, über technologische Raffinesse überlegene Supply-Chain-Entscheidungen zu treffen. Wir verarbeiten jedoch täglich wichtige Finanzdaten, daher hat die Sicherheit unserer Softwareplattform Priorität, und wir behandeln sie mit größter Ernsthaftigkeit. Anstatt Sicherheit als nachträgliche Maßnahme anzugehen, die durch Bürokratie geregelt wird, glauben wir fest an einen prinzipienbasierten Ansatz, der Planung und Proaktivität betont - wie durch unsere spezifische Softwaregestaltung, Personalbesetzung und Schulungswahl belegt.
Zielgruppe: Die IT-Abteilung
Zuletzt geändert: 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 ändert sich der Feinschliff der Sicherheitsbedenken immer. Probleme entstehen, wenn böswillige Akteure Software oder Menschen (oder beides) ausnutzen. Sicherheit kann daher nur durch die vernünftige Anwendung allgemeiner Prinzipien angegangen werden.
Sicherheit durch Design
Wir glauben, dass Design einer der am meisten unterschätzten Aspekte der Softwaresicherheit ist. Hier umfasst Design die grundlegenden Entscheidungen, die getroffen wurden, um die Software zu entwickeln. 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 einfache Blob-Speicherung als rein passive Speicherschicht. Allein diese Entscheidung verhindert ganze Gruppen von Sicherheitsproblemen, wie z.B. SQL-Injektionsangriffe, da es einfach keine SQL-Datenbank gibt, die angegriffen werden kann. 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 verfolgt und können rückgängig gemacht werden. Dieser Schritt erschwert das Löschen von Daten (durch jeden, einschließlich Angreifer) erheblich, ebenso wie das Manipulieren von Lokads Protokollen.
Die meisten Anbieter von Unternehmenssoftware erkennen nicht an, dass grundlegende Designentscheidungen das Fundament ihrer Softwareprodukte sind. Als Ergebnis sind ihre Sicherheitsprobleme endlos. Wenn beispielsweise Konfigurierbarkeit - fast immer eine Anforderung für 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 Möglichkeit hat, direkt mit dem Betriebssystem und seinen Subsystemen wie dem Dateisystem zu interagieren.
Sicherheit durch Kultur
Keine Technologie und sicherlich kein Prozess kann Software sicher machen, wenn den Menschen die Sache einfach egal ist. Daher geben wir unser Bestes, um Lokad - sowohl seine Technologien als auch seine Prozesse - zu etwas zu machen, das echte Sorge wert ist. Im Kontext von Unternehmenssoftware ist dies schwierig, da das Interesse abstrakt ist und von den individuellen Perspektiven und Motivationen der Menschen getrennt ist1.
Zunächst stimmt Lokad seine Marketingbotschaften so weit wie menschenmöglich mit der Realität seines Geschäfts ab. Wir tun dies, ob es uns Zustimmung oder Kritik einbringt. Dies steht im starken Kontrast zu vielen Unternehmensanbietern, die unvernünftige (und oft phantasievolle) öffentliche Behauptungen aufstellen 2. Wenn letzteres geschieht, hören scharfe Mitarbeiter - diejenigen, 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ührt zu Selbstzufriedenheit, und Sicherheitsprobleme folgen. Oft kündigen diese Mitarbeiter das Unternehmen, und die “leichtgläubigen” Mitarbeiter bleiben zurück - diejenigen, die den Unterschied nicht erkennen. Leichtgläubigkeit ist in Bezug auf Sicherheit genauso wenig wünschenswert wie Gleichgültigkeit.
Zweitens fördert Lokad bei seinen Mitarbeitern eine Mischung aus Neugierde und gesundem Skeptizismus in allen Bereichen unseres Geschäfts, sowohl technisch als auch nicht technisch, einschließlich Sicherheit. Dadurch entsteht Flexibilität bei der Überarbeitung und Aktualisierung von Praktiken, da Mitarbeiter geschult und ermutigt werden, ihren Beitrag zu leisten. Diese Plastizität ist nützlich, um böswillige Akteure vorauszusehen, da diese bekanntermaßen immer kreativere Angriffsmethoden entwickeln. Glücklicherweise ist diese Denkweise auch für die Supply Chain äußerst wünschenswert, da problematisches Verhalten - auch wenn es nicht unbedingt kriminell ist - in der Supply Chain weit verbreitet ist 3.
Sicherer durch Training
Wir schulen aktiv unser gesamtes Personal, um Cyberbedrohungen besser zu verstehen und wie man ihnen entgegenwirken kann. Im Gegensatz zu Design und Kultur ist die Sicherheitsschulung größtenteils ein Top-Down-Prozess. Obwohl bottom-up Denken seinen Platz hat, ist diese Art von Schulung gegen die meisten Computersicherheitsrisiken von Natur aus schwach. Einfach ausgedrückt, selbst wenn Menschen geschult sind, etwas nicht zu tun, kann Lokad nicht davon ausgehen, dass niemand jemals diese Sache tun 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 Maschinen gefährden könnten. Wir stellen sicher, dass immer dann, wenn möglich, eine Zwei-Faktor-Authentifizierung verwendet wird. Wir schulen unser Personal, mit möglichst wenigen Berechtigungen auf ihren Arbeitsstationen zu arbeiten. Wir stellen sicher, dass jeder weiß, wie Social Engineering funktioniert, was selbst die klügsten Menschen täuschen kann.
Allgemein konzentriert sich die Sicherheitsschulung darauf, das Bewusstsein dafür zu erhöhen, wie Software und Prozesse von böswilligen Akteuren zweckentfremdet und beschädigt werden können. Angesichts des Umfangs der Schulung, der erforderlichen Fähigkeiten und des erforderlichen Fachwissens, um solche nuancierten Angriffe zu verhindern, hat Lokad im Vergleich zu den meisten Unternehmen vergleichbarer Größe in diesem Bereich nur sehr wenige Praktikanten. Kurz gesagt, setzen wir lieber auf ein stabiles, hochqualifiziertes Team auf lange Sicht.
Häufig gestellte Fragen (FAQ)
1. Praktiken
1.1 Haben Sie Sicherheitsgarantien?
Ja. Sicherheitsgarantien ist ein Oberbegriff für verschiedene Praktiken wie Sicherheitsverstärkung, Sicherheitstests und Schwachstellenmanagement. Bei Lokad wird Sicherheitsverstärkung in erster Linie durch Design angegangen. Durch spezifische Designentscheidungen eliminieren wir ganze Klassen von Schwachstellen, was wiederum den Bedarf an Verstärkung selbst eliminiert. Zum Beispiel verlässt sich Lokad nicht auf eine “programmatische” Speicherschicht wie eine relationale Datenbank, sondern auf einen einfachen Schlüssel-Wert-Speicher. Dadurch werden alle SQL-Injektionsvektoren eliminiert. Darüber hinaus werden Sicherheitstests durch eine vielfältige Reihe von Methoden angegangen, einige automatisiert und einige manuell, wie z.B. Penetrationstests von Dritten. Für das Schwachstellenmanagement haben wir ein Bug-Bounty-Programm und einen umfangreich automatisierten Freigabemanagementprozess, 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 unsicherer machen. Diese Konformitätsprozesse betonen eine bürokratische Denkweise, die dem erforderlichen Ansatz zur Sicherung von Software entgegengesetzt ist. Zum Beispiel erfordern diese Zertifizierungen die Erstellung von Dokumenten und die Einrichtung von Ausschüssen. Offen gesagt ist die Vorstellung, dass Dokumente und Ausschüsse etwas Substanzielles für die Sicherheit von Software liefern, stark umstritten und etwas, das Lokad keineswegs akzeptiert.
In Softwarekreisen wird Sicherheit normalerweise erreicht, indem weniger getan wird, nicht mehr; indem die Bemühungen von Softwareingenieuren genutzt werden, die sich auf die Sicherheit von Software spezialisiert haben, anstatt zusätzliche Teams von Nicht-Spezialisten zu schaffen. Als anekdotischen Beweis kann man sich einige der schwerwiegendsten Cybersicherheitskatastrophen wie Heartbleed oder Log4Shell vorstellen. Diese Katastrophen hätten wahrscheinlich verhindert werden können, wenn die Tausenden von “zertifizierten” Softwareunternehmen sich dafür entschieden hätten, das Drittanbietercode - oft die eigentliche Ursache von Problemen - Korrekturlesen vorrangig zu behandeln, anstatt willkürliche kommerzielle Gütesiegel zu verfolgen.
Insgesamt sind wir der Meinung, dass diese Zertifizierungen Marketing-Gimmicks sind, die Unternehmen in eine trügerische Sicherheit (sowohl im übertragenen als auch im wörtlichen Sinne) wiegen.
1.3 Befolgen Sie OWASP-Praktiken?
Ja. OWASP bietet in seinen Leitfäden eine umfangreiche Checkliste gegen häufige Schwachstellen in Software. Dies ist eine umfangreiche, hochwertige Zusammenstellung, die von Lokad-Ingenieuren genutzt wird, um unsere Software vor allen von OWASP identifizierten Problemen zu schützen. Durch seine Designentscheidungen eliminiert Lokad jedoch weitgehend ganze Klassen von häufigen Schwachstellen, die von OWASP hervorgehoben werden. Zum Beispiel:
Passwortverwaltung: Durch die Delegierung 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 in Bezug auf Passwörter überflüssig macht.
Protokollierung: Das von Lokad übernommene Event Sourcing-Design protokolliert ausnahmslos alles. Wenn eine Aktion nicht protokolliert wird, hat sie für das System nie stattgefunden. Dadurch werden die meisten Punkte auf der Protokollierungs-Checkliste hinfällig.
Datenbanksicherheit: Die Persistenzschicht von Lokad umfasst 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 überflüssig.
Im Allgemeinen bevorzugen wir es, fehleranfällige Designmuster in der Entwicklung zu vermeiden, die die Notwendigkeit solcher Checklisten überhaupt erst entstehen lassen.
1.4 Sind Sie GDPR-konform?
Ja. Die Optimierung der Lieferkette, wie sie von Lokad geliefert wird, erfordert keine personenbezogenen Daten. Wir betrachten personenbezogene Daten eher als Haftungsrisiko als als Vermögenswert. Daher empfehlen wir unseren Kunden dringend, keine personenbezogenen Daten an uns zu übertragen. Diese Empfehlung ist in der Regel Bestandteil unserer Vertragsvereinbarungen. Durch den Verzicht auf personenbezogene Daten und somit auf die Verarbeitung personenbezogener Daten eliminieren wir weitgehend Bedenken und Protokolle im Zusammenhang mit dem Schutz solcher Daten, wie z.B. der DSGVO oder ähnlicher Vorschriften.
1.5 Erfüllen alle Drittanbieterdienste/-lösungen (die Zugriff auf personenbezogene Daten ermöglichen) in Lokads Lösung die Anforderungen des Datenschutzbeauftragten (DPO)?
Ja. Wie bereits in Practices 1.4 erwähnt, erfordert die Lieferkettenoptimierung, wie sie von Lokad geliefert wird, keine personenbezogenen Daten. Daher empfehlen wir unseren Kunden dringend, keine personenbezogenen Daten an uns zu übertragen.
Es sollte beachtet werden, dass Lokads Lösung nur eine sehr kurze Liste von Drittanbietern umfasst, 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 vernünftige Entscheidungen, da es keine branchenweite Einigung darüber gibt, was “die besten Software-Sicherheitspraktiken” ausmacht. Die Software-Sicherheit befindet sich von Natur aus in einem ständigen Wandel und passt sich einer Umgebung an, die mit geschickten neuen Bedrohungen und Angriffsvektoren gefüllt ist. Daher orientieren wir uns nicht kategorisch an Drittanbietern, was die besten Software-Sicherheitspraktiken sind. Stattdessen definieren wir, was für unsere Kunden am besten ist. Dadurch können wir gute Praktiken übernehmen, ohne weniger empfehlenswerte Praktiken starr zu befolgen, nur weil sie populär 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, einschließlich Lokad. In der Regel gibt es eine gewisse Koordination zwischen dem Entwicklungsteam von Lokad 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 Exploit offen ist.
1.8 Führen Sie regelmäßig externe Audits durch?
Nein. Das heißt jedoch nicht, dass wir uns nicht gerne einem externen Audit unterziehen würden, wenn die Operation vom Kunden finanziert wird. Viele unserer großen Kunden haben in unseren Vertragsvereinbarungen Bestimmungen für solche Audits. 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. Die größte Eventualität, der Lokad begegnet ist, ist die hypothetische Einstellung des Unternehmens selbst. Lokad arbeitet als SaaS-Lösung, jedoch haben einige unserer großen Kunden Bestimmungen in ihren Vertragsvereinbarungen, um vollständige Snapshots unserer Codebasis anfordern zu können. Diese Snapshots werden bei einem vereinbarten Dritten in Verwahrung gegeben, so dass der Kunde im Falle einer Einstellung von Lokad automatisch Zugriff auf die Codebasis in Verwahrung und eine genehmigte Lizenz zur Erstellung einer eigenen Instanz des Lokad-Dienstes erhält.
1.10 Haben Sie einen Krisenkommunikationsplan?
Ja. Für jeden Kunden haben wir einen festgelegten Ansprechpartner in ihrer Organisation. Auf unserer Seite gibt es mindestens zwei Mitarbeiter bei Lokad - einen Hauptansprechpartner und einen Vertreter (in der Regel zwei unserer Supply Chain Scientists) -, die dafür verantwortlich sind, dringende Nachrichten an den Kunden zu übermitteln. In der Praxis handelt es sich bei den meisten Krisen, mit denen wir konfrontiert sind, nicht um Software-Sicherheitsprobleme, sondern um Lieferkettenprobleme - Notfälle, die Lokad anhand der 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 hat. Das IT-System des Kunden sollte nur Daten von Lokad abrufen und senden. Dieser Ansatz soll die Möglichkeit eines Sicherheitsvorfalls bei Lokad minimieren, der sich auf das IT-System des Kunden ausbreiten könnte. Darüber hinaus empfehlen wir auch die Verwendung eines SSO (Single Sign-On)-Verfahrens, da dies das hypothetische Szenario ausschließt, dass ein Passwort, das zur Anmeldung bei Lokad verwendet wird, abgefangen wird und später zur Kompromittierung eines der IT-Systeme des Kunden verwendet wird.
1.12 Wie sichern Sie Ihr Netzwerk?
Unser Design basiert auf einer Zero-Trust-Architektur, das heißt, es werden nur den richtigen Personen zu jedem Zeitpunkt Zugriff auf Daten gewährt. Allein die Anwesenheit in unserem Netzwerk gewährt keine automatische Berechtigung 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 gehalten wird.
Lokad verwendet zwei bemerkenswerte Netzwerke. Das erste ist Microsoft Azure, das zur Bereitstellung unserer Lösung verwendet wird. Die Sicherheit des Microsoft Azure-Netzwerks liegt vollständig in der Verantwortung von Microsoft. Wir nutzen keine “fortgeschrittenen” Netzwerkfunktionen - wie sie von Microsoft Azure angeboten werden - über grundlegende Lastenausgleicher hinaus.
Das zweite Netzwerk ist das lokale Netzwerk unserer Zentrale in Paris. Die Sicherheit des lokalen Netzwerks wird intern vom Engineering-Team von Lokad verwaltet. Unser lokales Netzwerk beherbergt keine Komponente oder System, das 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 gültig für Entwicklung und Produktion sind?
Ja. Im Vergleich zu den meisten Enterprise-Software-Anbietern hat Lokad nur sehr wenige Abhängigkeiten. Alle unsere wichtigsten Abhängigkeiten sind glaubwürdige und weit verbreitete Open-Source-Projekte (z. B. .NET von Microsoft, React von Facebook). Dies macht unseren internen Prüfungsprozess zu diesem speziellen Punkt zu einer unkomplizierten Angelegenheit.
1.14 Wie verwalten Sie größere Veränderungen in Organisation und Prozessen in Bezug auf Sicherheit?
Da Lokad von Anfang an vernünftige Sicherheitsdesigns und -praktiken übernommen hat, ist es selten, dass eine Änderung jeglicher Größenordnung (klein oder groß) die Sicherheit beeinträchtigt (selbst hypothetisch). In der gesamten Geschichte von Lokad gab es nur 3 Ereignisse, die aus sicherheitstechnischer Sicht als wirklich bedeutsam betrachtet werden können: 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 Google Authentication zu Microsoft Azure AD im Jahr 2022.
Für jedes dieser Ereignisse wurde die Migration Monate im Voraus von Lokads Software-Engineering-Team vorbereitet. Vor dem geplanten Wechsel wurden relevante Schulungsmaterialien und Schulungssitzungen durchgeführt, um die Einsatzbereitschaft aller Lokad-Mitarbeiter sicherzustellen. Schließlich haben wir nach jedem Migrationsereignis dafür gesorgt, 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 mit ziemlicher Sicherheit ähnlich vorgehen.
1.15 Wie verwalten Sie das Ende eines Vertrags?
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 selbst 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äftstätigkeit des Kunden zu stören). Um dies zu verhindern, würden Lokad und der Kunde gemeinsam daran arbeiten, einen vertraglich festgelegten Prozess zu übernehmen, der nicht leicht 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 Wie 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 Lokad bereitgestellten Service der Supply Chain Scientists für den Kunden verbunden ist (d.h. den von Lokad bereitgestellten Ingenieuren). Die genauen Details werden im Servicevertrag zwischen dem Kunden und Lokad verhandelt und festgelegt. Diese beiden Gebühren stellen ein “All-inclusive”-Paket mit Lokad dar. Es fallen keine zusätzlichen Wartungsgebühren, Lizenzgebühren, Gebühren für Drittanbieterintegratoren, Gebühren für Drittanbieterberater usw. an. Das Paket hat Grenzen, sowohl im Umfang als auch im Maßstab, 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 die Schulungen bereitstellen?
Ja, auf Anfrage des Kunden können wir eine Vertragsvorlage bereitstellen, die eine “Grundvereinbarung” 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, eine erste Diskussion mit einem potenziellen Kunden zu führen, um die Besonderheiten der in Betracht gezogenen Supply Chain-Initiative zu klären. Dies hilft uns, den relevantesten vertraglichen Rahmen für die Situation zu gestalten.
1.18 Bieten Sie Schulungen (vor Ort/e-Schulungen) an?
Ja, Lokad bietet sowohl Schulungen vor Ort als auch Fernschulungen an. Die genauen Details dieser Schulungen werden im Rahmen des Vertrags vereinbart. Darüber hinaus verfügt Lokad über umfangreiche öffentliche technische Dokumentationen und eine detaillierte Reihe von öffentlichen Supply Chain-Vorlesungen. Diese Vorlesungen behandeln Lokads Technologie und Supply Chain-Perspektive.
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 die vorausschauende Optimierung der Supply Chain und kontrolliert daher die Operationen nicht direkt. Unser Einfluss ist weitgehend indirekt, in der Regel durch die Optimierung der Ressourcenzuweisung. 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 Ist die Softwareentwicklung mit integrierter Bedrohungsanalyse verbunden?
Ja. Dies ist der Hauptgrund, warum wir Sicherheitsbedenken “von Anfang an” angehen. Durch die Beseitigung ganzer Klassen von Bedrohungen in der Designphase halten wir die Gesamtbedrohungsanalysepraxis besser handhabbar. Die Bedrohungsanalyse umfasst auch “Supply Chain-Angriffe”. Dies ist ein weiterer Grund, warum wir so großen Wert darauf legen, die Anzahl der Abhängigkeiten von Drittanbietern 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 geübt?
Ja. Es gibt viele verschiedene Arten von Vorfällen. Einer der häufigsten ist, dass das Unternehmen des Kunden selbst gehackt wird. Im Falle von Ransomware führt dies manchmal dazu, dass die Lokad-Daten versehentlich der einzige noch zugängliche Datensatz sind. Bei Identitätsdiebstahl kommt es manchmal zu Versuchen, auf das Lokad-Konto über gestohlene Zugangsdaten zuzugreifen. Die genauen Details der verschiedenen Vorfallmanagementprozesse werden gemeinsam mit dem Kundenunternehmen festgelegt und in der Regel vom für das Konto zuständigen Supply Chain Scientist bei Lokad überwacht (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 häufig durch bedeutende Ereignisse wie bemerkenswerte Sicherheitsverletzungen in der Softwarebranche vorangetrieben.
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 beeinflussen könnten?
Ja. Die Lokad-Plattform ist jedoch im Wesentlichen ein Monolith, der nicht auf “unterstützende Funktionen” angewiesen ist, abgesehen von einigen grundlegenden Grundlagen wie dem Blob Storage und 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 entsprechenden Zugriffsrechten werden für die Ausführung von Systemprozessen verwendet. Lokad verwendet Dämonen in Form von systemd-Diensten, die immer als Benutzer mit möglichst wenigen Privilegien 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 “Benutzerland” und nicht als “System” -Prozesse kategorisiert.
1.26 Gibt es einen formalisierten Risikosteuerungsplan, der von der Geschäftsleitung genehmigt wurde und die Anforderungen des Enterprise Risk Management-Programms definiert?
Ja, wir haben einen formalisierten Risikosteuerungsplan, der von der Geschäftsleitung genehmigt wurde.
Dieser Plan legt die Anforderungen und Richtlinien für unser Enterprise Risk Management (ERM) Programm fest. Es ist darauf ausgelegt, Risiken im gesamten Unternehmen strukturiert und konsistent zu identifizieren, zu bewerten, zu steuern und zu überwachen.
Unser Risikosteuerungsplan wird regelmäßig überprüft und aktualisiert, um sicherzustellen, dass er relevant bleibt und mit unseren Organisationszielen 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 dem ein Verantwortlicher zugewiesen wurde, der es pflegt und überprüft?
Ja, wir haben ein umfassendes physisches Sicherheitsprogramm, das von der Geschäftsleitung genehmigt wurde. Dieses Programm wurde allen relevanten Beteiligten gründlich mitgeteilt, um Bewusstsein und Einhaltung sicherzustellen.
Darüber hinaus haben wir einen Verantwortlichen benannt, der für die Pflege, 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 den bewährten Verfahren und unseren Organisationszielen entspricht.
1.28 Werden Bewertungen der physischen und Umweltrisiken durchgeführt, bevor der Standort oder das Gelände einer Einrichtung festgelegt wird, an dem sich Systeme befinden?
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 sich unsere Systeme in den Rechenzentren von Microsoft Azure befinden, 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 umfasst die Analyse von Faktoren wie dem Potenzial für Naturkatastrophen, der Zugänglichkeit, der Stabilität der Infrastruktur und mehr.
Durch die Nutzung der Azure-Rechenzentren sind wir zuversichtlich, dass diese Bewertungen umfassend durchgeführt wurden, um das höchste Maß an physischer Sicherheit und Umweltbeständigkeit 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-Methode durchgesetzt werden kann. Eine solche Vorgehensweise führt zwangsläufig zu unerwünschten Ergebnissen, die den ursprünglichen Zielen zuwiderlaufen.
Berühmt ist, dass Enron einen Verhaltenskodex hatte. Dieser Kodex betonte Respekt, Integrität, Kommunikation und Exzellenz. Der Enron-Skandal, der 2001 ans Licht kam, enthüllte, dass das Unternehmen in massive Bilanzbetrügereien 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 legt Lokad Wert 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 und nicht das Ergebnis eines bestimmten Programms.
1.30 Gibt es eine interne Prüfung, 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 Prüfungen, Risikomanagement oder Compliance zu haben, haben wir diese Bereiche definitiv priorisiert. Wir haben speziell dafür zuständige Personen mit Fachkenntnissen in diesen Bereichen, die mit der Bearbeitung und Überwachung dieser wichtigen Aufgaben betraut sind.
Diese Personen berichten direkt an die oberste Führungsebene von Lokad und stellen sicher, dass die Lösung ausstehender regulatorischer oder Compliance-Probleme mit höchster Priorität behandelt wird und die erforderliche Aufsicht auf höchster Ebene unserer Organisation erhält.
1.31 Gibt es eine drahtlose Richtlinie oder ein Programm, das von der Geschäftsleitung genehmigt, an die entsprechenden Interessengruppen kommuniziert und ein Verantwortlicher benannt wurde, der diese pflegt und überprüft?
Ja, Lokad hat eine klar definierte drahtlose Richtlinie, die von der Geschäftsleitung genehmigt und an alle relevanten Interessengruppen 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 stellt sicher, 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, das aufgrund seiner überlegenen Leistung und erhöhten Sicherheit priorisiert wird. Die Wi-Fi-Netzwerke sind hauptsächlich für Besprechungen und bieten Flexibilität in bestimmten Szenarien vorgesehen.
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 den sich entwickelnden Anforderungen und Herausforderungen gerecht wird.
2. Authentifizierung
2.1 Erzwingen Sie die Authentifizierung für alle Zugriffe?
Ja. Der Zugriff auf Kundendaten und/oder jede wesentliche Funktion der Lösung erfordert eine vorherige Authentifizierung. Einige Kontaktpunkte sind jedoch aus Gründen der Notwendigkeit nicht authentifiziert. Der Zugriff auf die Login-Webseite erfordert beispielsweise keine vorherige Authentifizierung (da die Authentifizierung der eigentliche Zweck 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 zum Überprüfen dient, ob eine Maschine aktiv ist). Es sollte beachtet werden, dass nicht authentifizierte Endpunkte keine sensiblen Daten, geschweige denn tatsächliche Kundendaten, offenlegen.
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 “unsicheren 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 Zwei-Faktor-Authentifizierung wie EZToken, Google Authenticator oder Microsoft Authenticator?
Ja. Die Zwei-Faktor-Authentifizierung wird über die delegierte Authentifizierung über SAML erreicht. Über SAML verwaltet Lokad weder den ersten Authentifizierungsfaktor noch den zweiten, da dieser Prozess delegiert wird.
2.5 Unterstützen Sie das OAuth2-Authentifizierungsprotokoll?
Standardmäßig unterstützt Lokad das SAML-Authentifizierungsprotokoll. Dieses Protokoll wird von den großen 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 stellen wir fest, dass die verschiedenen OAuth2-Implementierungen, die im Bereich der Unternehmenssoftware existieren, tendenziell weitgehend inkompatibel sind. Wenn OAuth2 jedoch eine absolute Anforderung ist, können wir gemäß vertraglicher Vereinbarung eine bestimmte 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ützt 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 nachdrücklich, können es jedoch letztendlich 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 erzwingen?
Ja, aber nur in begrenztem Umfang. Was die Software-Sicherheit betrifft, wird die Forderung nach minimaler Passwortkomplexität mittlerweile weitgehend als schlechte Praxis anerkannt. Endbenutzer reagieren schlecht (und vorhersehbar) auf übermäßig strenge Anforderungen an die Passwortkomplexität, was zu einer Verringerung des Sicherheitsniveaus führt. Darüber hinaus betrachten wir solche Passwortanforderungen als “Bloatware”, die die Komplexität einer sicherheitskritischen Software (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 erzwingen?
Ja, aber wir tun es nicht. Ähnlich wie bei minimaler Passwortkomplexität (siehe Authentifizierung 2.8) wird die geplante Passwortrotation mittlerweile weitgehend als schlechte Praxis in der Software-Sicherheit anerkannt. Endbenutzer reagieren schlecht (und vorhersehbar) auf geplante Passwortrotationen. Die Sicherheit kann sogar geschwächt werden, da Mitarbeiter häufig 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 auch die Passwortrotation als “Bloatware”, die die Komplexität einer sicherheitskritischen Software (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-Hashing-Funktion. Als allgemeine Regel empfehlen wir dringend die Verwendung von SSO anstelle der Verwendung von traditionellen Passwörtern/Strategien. Durch SSO ist es nicht erforderlich, ein spezielles Passwort für Lokad einzuführen.
2.11 Ermöglicht die Lösung von Lokad nach einer festgelegten Anzahl von Authentifizierungsfehlern CAPTCHA?
Ja, allerdings ü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 sollten. 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, um diese durchzusetzen?
Ja. Unsere allgemeine Sicherheitsrichtlinie für Passwörter lautet “keine Passwörter”. Wir empfehlen dringend SSO, das die Notwendigkeit beseitigt, Passwörter speziell für Lokad einzuführen.
2.13 Zentralisieren Sie das Benutzermanagement?
Ja. Lokad hat ein eigenes zentrales Benutzermanagement für die von uns betriebene Lösung. Dieses Subsystem wurde von Lokad implementiert und umfasst auch den Zugriff der Lokad-Mitarbeiter - 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 keine Gebühren erheben, 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 in der Regel für den clientseitigen “Robot-Upload”-Dienst des Kunden, der für das Hochladen von Daten in Lokad zuständig ist. Im Rahmen unserer RBAC (Rollenbasierte Zugriffskontrolle) haben wir eine dedizierte Rolle (namens “Uploader”), die minimale Rechte für diesen speziellen Anwendungsfall bietet.
2.15 Bieten Sie sichere VPN-Verbindungen an?
Nein. Die Verbindungen der Endbenutzer werden über verschlüsselte Kanäle (in der Regel TLS) verwendet.
2.16 Dürfen sich Benutzer von mehreren Geräten aus anmelden?
Ja, innerhalb bestimmter 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 Missbräuchen entgegenzuwirken.
2.17 Hat die Lösung die Möglichkeit, einen Benutzer zwangsweise zu sperren und/oder abzumelden (wenn er als bösartig angesehen wird)?
Ja. Diese Funktion erfordert “Owner”-Zugriffsrechte im Lokad-Konto.
2.18 Meldet das System einen inaktiven Benutzer automatisch ab, nach einer bestimmten Zeit der Inaktivität?
Ja, wobei “Inaktivität” nicht der entscheidende Faktor ist. Lokad meldet Benutzer automatisch nach einer bestimmten Zeit ab. Benutzer können die Abmeldung 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 standardmäßigen Mustern, die mit Sicherheit im Hinterkopf entworfen wurden. 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 dringend die Verwendung von Single Sign-On (SSO) und föderierten Identitätssystemen für Mitarbeiter von Kunden, die sich mit unseren Systemen verbinden. Diese Systeme unterstützen bewährte Verfahren im Bereich der Anmeldeinformationenverwaltung und stellen sicher, dass Anmeldeinformationen auf sichere Weise kommuniziert werden, oft unter Verwendung separater Kommunikationskanäle oder -methoden für Benutzer-IDs und Authentifizierungsmechanismen.
Es ist erwähnenswert, 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 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 einen Mitarbeiter aus seinem Identitätssystem entfernt, wird der Zugriff auf Lokad gleichzeitig beendet. Diese Methode 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 Auswirkungen einer vorzeitigen Deaktivierung eines Kontos an und ergreift aktive Maßnahmen, um solche Szenarien zu vermeiden. Um unbeabsichtigte Störungen zu vermeiden, werden 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 den betrieblichen Anforderungen unserer Kunden entsprechen.
3. Autorisierung
3.1 Bietet die Lösung feingranulare Zugriffsrechte?
Ja. Die Lokad-Lösung umfasst ein granulares RBAC (Role-Based Access Control) Subsystem. Dadurch kann der Kunde steuern, auf welche “Projekte” und “Dateien” im Lokad-Konto zugegriffen werden kann (und von wem). Das RBAC verfügt über eine eigene Web-Benutzeroberfläche (Dashboard). Es steht allen Benutzern mit der Bezeichnung “Owner” im Lokad-Konto zur Verfügung. Weitere Informationen finden Sie in unserer Dokumentation zu Benutzerrollen und Berechtigungen.
3.2 Ermöglicht die Lösung dem Kunden, den Zugriff gemäß dem Prinzip des geringsten Privilegs (PoLP) zu konfigurieren?
Ja. Die Lokad-Lösung umfasst ein granulares RBAC (Role-Based Access Control) Subsystem, das zur Umsetzung des PoLP verwendet werden kann. Durch Envision (die DSL der Lösung) geht Lokad jedoch weit über die meisten Unternehmenssoftware hinaus, was dieses Prinzip betrifft.
Durch Envision hat Lokad ganze Gruppen von Systemprivilegien eliminiert, die für die Optimierung der Supply Chain einfach irrelevant sind. Was bleibt, ist zwar schlank, aber immer noch weitgehend konfigurierbar. Ähnlich eliminiert das maßgeschneiderte Dateisystem von Lokad auch ganze Gruppen von unnötigen Systemprivilegien.
3.3 Werden Zugriffsrechte gemäß dem Prinzip des geringsten Privilegs durchgesetzt?
Ja, obwohl was als “geringstes akzeptables” Privileg gilt, letztendlich von unseren Kunden entschieden wird. Lokad kann einseitig nicht bestimmen, wer von einer “Besitzer” Bezeichnung im Personal unserer Kunden profitiert. Wir können jedoch in dieser Hinsicht Unterstützung bieten. In der Praxis klären wir (schriftlich) die gewünschte Organisation und die entsprechenden Zugriffsrechte für unsere “verwalteten” Kunden - diejenigen, die von Lokads Team von Supply Chain Scientists unterstützt werden.
3.4 Hat die Lösung die Möglichkeit, eine bestimmte Entität im System vor bestimmten 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 Haben Sie eine Klassifizierung für Daten (Sensitivitätsstufen) und werden die Kontrollen 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 “Besitzer” des Kontos. Diese Bezeichnung ist die höchste und privilegierteste des RBAC (Role-Based Access Control). Alle anderen Daten innerhalb des Lokad-Kontos können gemäß einer benutzerdefinierten Sensitivitätsklassifizierung segmentiert werden. Diese benutzerdefinierte Klassifizierung kann sowohl auf die ursprünglichen Daten (wie sie vom Kunden hochgeladen wurden) als auch auf die transformierten Daten (das Ergebnis von Datenverarbeitungen innerhalb der Lokad-Plattform) angewendet werden.
Weitere Informationen zu Zugriffskontrollen und Bezeichnungen finden Sie in den 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 (Role-Based Access Control) erfolgen synchron, d.h. Aktualisierungen werden innerhalb weniger Sekunden (in der Regel weniger) aktiv. 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 (bei Lokad als “Projektdurchläufe” bezeichnet) unterbrechen. 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 Beenden 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 Berechtigungsebene?
Ja, obwohl die Lösung nicht dazu gedacht ist, personenbezogene Daten (über die Authentifizierungsidentifikatoren der Mitarbeiter mit Zugriff auf die Lösung hinaus) zu speichern. Dies gilt sowohl für Lokad als auch für den Kunden. Innerhalb der Lösung haben nur Mitarbeiter mit der Bezeichnung “Besitzer” Zugriff auf die Liste der Benutzer. Für die Optimierung der Supply Chain benötigt Lokad keine (oder profitiert nicht von) personenbezogenen Daten, und wir haben vertragliche Bestimmungen zu diesem Thema (erläutert in Practices 1.4 & Practices 1.5).
Weitere Informationen zu Zugriffskontrollen und Bezeichnungen finden Sie in den Antworten 3.1, 3.2 und 3.3.
3.8 Ermöglicht die Lösung die Verwendung von Suchfiltern für personenbezogene Daten (PII), um Platzhalter-Suchen zu verhindern?
Ja. Ein Benutzer mit der Bezeichnung “Besitzer” 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 die Liste der Benutzer mit Zugriff auf ihr eigenes Konto vollständig überprüfen können müssen.
3.9 Ist das System mit WAF (Web Application Firewall)-Technologie ausgestattet?
Nein. WAF ist ein grundsätzlich gefährliches Design, da es gegen das Sicherheitsprinzip des “geringsten Privilegs” verstößt: Eine Komponente erhält enorme Privilegien, um als “Man in the Middle” zu agieren. Dadurch wird die WAF selbst zu einem Hauptziel für Angreifer und erweitert die Angriffsfläche der Plattform erheblich. Lokad überwacht jedoch den Webverkehr und abnormales Benutzerverhalten auf unserer eigenen Plattform genau. Diese Fähigkeiten sind jedoch Teil der Plattform selbst und werden daher nicht an privilegierte isolierte Softwarekomponenten von Drittanbietern delegiert.
Siehe auch Mitarbeiter 6.6.
3.10 Ist das Netzwerk mit IPS (Intrusion Prevention System)-Technologie ausgestattet?
Nein. IPS ist ein grundsätzlich gefährliches Design, da es gegen das Sicherheitsprinzip des “geringsten Privilegs” verstößt: Eine Komponente erhält enorme Privilegien, um als “Man in the Middle” zu agieren. Dadurch wird das IPS selbst zu einem Hauptziel für Angreifer und erweitert die Angriffsfläche der Plattform erheblich. Um die Lokad-Plattform gegen Eindringlinge abzusichern, beginnt unser Design damit, die Angriffsfläche zu minimieren. Wir sind der Meinung, dass es viel sicherer ist, Pfade für Eindringlinge von vornherein zu eliminieren, anstatt 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-Rate-Limits und unsere eigenen spezifischen Komponenten (wie z.B. frühes Scheitern bei ungültiger Authentifizierung).
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 dem von ‘Teleport’ ähnelt. 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 administrativen Zugriffs (und einen Prozess, der eine zuverlässige Audit-Spur erzeugt)?
Ja. Siehe Logging und Monitoring 5.1 und 5.11.
3.14 Gibt es einen systematischen und regelmäßigen Zugriffsrechtsüberprüfungsprozess (durchgeführt von einer autorisierten Person), bei dem administrative Zugriffsrechte mit allen 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 für das Konto zuständigen Supply Chain Scientist gewährt und überwacht - für unsere verwalteten Konten. Alternativ werden diese Rechte von dem Kundenunternehmen selbst gewährt und überwacht, wenn das Konto nicht direkt von Lokad/einem Supply Chain Scientist verwaltet wird.
3.15 Folgt Ihre Zugriffsbeschränkungspolitik dem Prinzip des “geringsten Privilegs”, bei dem nur notwendiger und genehmigter Datenverkehr zugelassen ist?
Ja. Wir wenden das Prinzip des geringsten Privilegs (PoLP) auf alle Zugriffsebenen unserer Infrastruktur an, einschließlich des Netzwerkverkehrs. Die Schwere 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 von überall her zugreifen, wie dies für den Inhalt 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ßer 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 aufwiegen könnten. Die Beschränkung ausgehender Verbindungen könnte begrenzte Sicherheitsvorteile bieten, aber auch Komplikationen einführen, die die Sicherheit unserer Produktionsumgebung möglicherweise beeinträchtigen.
3.17 Steht den Kunden/Klienten rund um die Uhr an 365 Tagen im Jahr eine besetzte Kommunikationsform (z. B. E-Mail, Webformular, Telefon usw.) zur Verfügung, um Sicherheitsvorfälle zu melden?
Ja, wir haben den Standard security.txt
implementiert, um die Meldung von Sicherheitsvorfällen zu erleichtern.
Der Ansatz security.txt
ist ein weit verbreitetes Muster in der Web-Sicherheit, bei dem eine spezifische Textdatei auf der Website platziert wird. Diese Textdatei enthält Informationen zur Meldung von Sicherheitslücken.
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 der in der ‘security.txt’ beschriebene Prozess überarbeitet werden kann, die aktuellsten und genauesten Informationen jedoch immer unter dieser Adresse verfügbar sind. Wir stellen sicher, dass die in der Datei genannten Kommunikationskanäle, ob 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 hosten und verarbeiten Sie die Daten?
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 sind wir noch nie in diese Situation gekommen. 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 auf 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 unserer Kunden intern nicht für andere Zwecke als diejenigen, die direkt zur Erfüllung der Aufgaben beitragen, für die uns unsere Kunden beauftragt haben. Lokad verkauft den Zugriff auf die Daten unserer Kunden nicht an Dritte. Lokad teilt den Zugriff auf Kundendaten nicht, außer mit den wenigen Hosting-Anbietern, die direkt zur Erfüllung der 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 Datenbankmanagement 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 von Lokad implementiert und betrieben.
4.4 Hat die Lösung die Möglichkeit, zwischen RDBMS-Datenbanken (PostgreSQL, Oracle, MySQL) und NoSQL-Datenbanken (Cosmos) zu wechseln?
Theoretisch ja, aber dies ist irrelevant, da die Lokad-Lösung keine RDMBS verwendet. Die Datenspeicherschicht der Lokad-Lösung basiert auf einem Ereignisspeicher und einem Schlüssel-Wert-Speicher. Dieser Ansatz unterscheidet sich erheblich von dem CRUD (Create-Read-Update-Delete)-Design, das in Unternehmenssoftware üblich ist. Da Lokad eine SaaS-Lösung ist, tragen wir die volle Verantwortung für die Datenspeicherung und die Vorwärtskompatibilität (um sicherzustellen, dass ältere Daten zugänglich bleiben).
4.5 Sind Dritte an der Ausführung der Lösung beteiligt?
Ja, insbesondere die zugrunde liegende Cloud-Computing-Plattform, die Lokad verwendet - Microsoft Azure. Die Liste der an der Ausführung der Lösung beteiligten Dritten ist sehr kurz und beschränkt sich auf die Infrastruktur auf niedrigerer Ebene. Lokad verwendet keine Dritten zur Entwicklung, Verwaltung oder Betrieb seiner eigenen Lösung. Insbesondere unsere Entwicklungsteams und unser technischer Support sind 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, die Lokad verwendet - Microsoft Azure, delegiert. Die Trennung der Netzwerk- und Serverebenen liegt daher größtenteils außerhalb des von Lokad verwalteten Perimeters. Innerhalb der Lokad-Lösung beschränken wir die Privilegien der Anwendungsschichten stark, damit sie ihre eigene Infrastruktur nicht verwalten können (z. B. haben die Anwendungsschichten 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 der Vertragsvereinbarung zwischen Lokad und seinen Kunden enthalten. Die Daten werden zunächst aus unserem primären Produktionssystem gelöscht und dann aus unserem Backup-System. Die letztere 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 zugänglich sind (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. Außerdem ist ein absichtlich langsamer Prozess zur dauerhaften Löschung erforderlich, um Social Engineering-Angriffe zu verhindern, z.B. ein Szenario, in dem ein Angreifer sich als Mitarbeiter eines Kunden ausgibt.
4.8 Hat die Lösung die Möglichkeit, Daten soft zu löschen?
Ja. Die Lokad-Lösung verwendet ein Event Sourcing-Design. Dadurch wird standardmäßig alles versioniert, sowohl die Benutzereinträge als auch die Änderungen am Dateisystem von Lokad. Daher 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 auf das Dateisystem - Teil der Lokad-Lösung - über Protokolle wie FTPS und SFTP zugegriffen werden kann. Dieser Zugriff ist umfassend, da alle Daten, die als Eingabe oder Ausgabe verwendet werden, in diesem Dateisystem gespeichert sind.
Allerdings gibt es bei Lokad keine transaktionale Datenbank, auf die zugegriffen werden könnte. Das nächstbeste Äquivalent in der Lokad-Architektur ist unser Event Store, und wir bieten keinen direkten Zugriff auf den Event Stream an. Es könnten jedoch Bestimmungen in der Vertragsvereinbarung getroffen werden, wenn ein Kunde bestimmte Extraktionen aus diesem Event Stream anfordern würde (sofern ein gültiger Anwendungsfall vorliegt).
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. Es steht auch eine webbasierte Benutzeroberfläche 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, Change Data Capture (CDC) von Echtzeit-Datenfeeds zu verarbeiten?
Ja, unter der Voraussetzung einer spezifischen vertraglichen Vereinbarung mit dem Kunden. Change Data Capture 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. Unsere Erfahrung zeigt, dass Echtzeit-Datenfeeds selten relevant sind, um Supply-Chain-Probleme anzugehen.
4.12 Können alle Daten innerhalb der Lösung exportiert werden?
Ja, alle über das Dateisystem im Lokad-Konto 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 speziell für die Supply-Chain-Analyse entwickelt wurde. Envision bietet umfangreiche Möglichkeiten, die Daten im Lokad-Konto 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 auf dem Back-End-Speicher von Lokad (durch Azure Storage-Verschlüsselung für Daten im Ruhezustand) als auch auf von Lokad ausgegebenen Geräten (durch BitLocker) verwendet. Lokad speichert keine PII auf Geräten ohne aktiviertes TDE.
4.16 Werden alle Passwörter und Geheimnisse, die in der Anwendung verwendet werden, verschlüsselt und sind nicht im Klartext im Quellcode, in Konfigurationsdateien, Build-Parametern usw. zugänglich?
Ja. Alle Secrets auf Plattformebene werden im Key Vault gespeichert, einem von Microsoft Azure angebotenen Dienst. Die Benutzerpasswörter werden intern gesalzen und mit Scrypt gehasht, wie es den Standardpraktiken entspricht.
4.17 Hat die Lösung die Möglichkeit, Datei-Uploads basierend auf Dateityp und -größe zu beschränken und auf schädlichen Inhalt zu überprüfen?
Ja, in begrenztem Umfang. In Bezug auf die Dateigröße erfordert die Optimierung der Supply Chain 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, auf schädlichen Inhalt zu überprüfen, verfügt Lokad nicht über diese Funktion. Unsere Lösung legt den Schwerpunkt auf das Teilen von plattformgeneriertem Inhalt. Darüber hinaus stellt das von uns gewählte Design sicher, dass die in Lokad generierten Dateien sicher sind, auch wenn die Eingabedateien dies 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 Aufbewahrungsfrist für Daten?
Lokad ist SaaS, daher tragen wir die Verantwortung, die geeignete Aufbewahrungsfrist für Daten zu wählen, und diese Dauer 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 ist es in der Regel sinnvoll, 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 für die Fehlerbehebung unerwarteter Verlangsamungen innerhalb der Plattform nützlich. Diese Daten sind äußerst granular und werden normalerweise nicht länger als einige Wochen aufbewahrt.
4.19 Stellen Sie eine Dokumentation der Datenstruktur zur Verfügung?
Ja, als Teil 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 zu einem typischen Lokad-Projekt gehört.
4.20 Ist die Segmentierung von Daten anderer Kunden Teil des Systemdesigns?
Ja, obwohl Lokad eine Multi-Tenant-Anwendung ist, werden die Daten auf Entwurfsebene zwischen Mandanten, d. h. Kundenkonten, getrennt. Diese Partitionierung ist ein integraler Bestandteil unseres Back-End-Designs. Dieses Design verhindert Programmierfehler, die dazu führen würden, dass die Daten eines Mandanten einem anderen Mandanten zugänglich gemacht werden, während alltägliche Funktionen innerhalb der Plattform weiterentwickelt werden. Der primäre zugrunde liegende Speicher, den Lokad verwendet - Blob Storage von Microsoft Azure - ermöglicht eine solche strikte Partitionierung auf Entwurfsebene.
4.21 Werden wirksame Maßnahmen ergriffen, um sicherzustellen, dass keine Kundendaten in Entwicklungs- und Testumgebungen verwendet werden?
Ja, standardmäßig hat das Softwareentwicklungsteam keinen direkten Zugriff auf Kundendaten. Wir haben umfangreiche “Mock”-Datenumgebungen und “Mock”-Datensätze entwickelt, um dem Softwareentwicklungsteam ein reibungsloses Arbeiten ohne Zugriff auf Kundendaten zu ermöglichen. Lokad verwendet auch intern seine eigene Plattform für die Datenverarbeitung (z. B. Analyse des detaillierten 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 lesende) Fragmente von Kundendaten für Diagnosezwecke abzurufen. Diese Pipeline stellt automatisch eine strikte und vollautomatische Minimierung der abgerufenen Daten sicher. Diese Pipeline stellt auch automatisch sicher, dass die Daten am Ende des Diagnosevorgangs gelöscht werden. Weitere Informationen zu dieser eingeschränkten Pipeline finden Sie unter 4.22.
4.22 Wenn die Entwicklung oder das Testen eine begrenzte Verwendung von Kundendaten erfordert, gibt es einen definierten Prozess, um eine sichere und vollständige Vernichtung der Daten in Entwicklungs- und Testumgebungen zu gewährleisten?
Ja, wir haben eine spezielle (nur lesende) Datenpipeline entwickelt, die ausschließlich für die außergewöhnliche Verwendung von Kundendaten zu Diagnosezwecken - in der Regel Leistungstests - vorgesehen ist. Diese Datenpipeline ist nur für einen eingeschränkten Teil des Softwareentwicklungsteams zugänglich.
Diese Datenpipeline wurde entwickelt, um automatisch das Fragment der Kundendaten zu minimieren, das für die interessierende Diagnose abgerufen wird. Diese Funktion ermöglicht es uns, mit einem sehr kleinen Bruchteil der ursprünglichen Datenmenge (wie sie im Kundenkonto zu finden ist) zu arbeiten. Darüber hinaus entfällt die Notwendigkeit für das Entwicklungsteam, manuell auszuwählen, welche Daten abgerufen werden sollen.
Schließlich löscht diese Datenpipeline die abgerufenen Daten automatisch am Ende des Diagnosevorgangs.
4.23 Sind alle physischen Standorte der Kundendaten bekannt und dokumentiert, einschließlich Backup- und Hochverfügbarkeitssystemen?
Ja. Alle Kundendaten werden in den physisch gesicherten Rechenzentren von Microsoft Azure, einschließlich Backups, gespeichert. Wir speichern Kundendaten nicht lokal (d. h. auf den Lokad-Servern) 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 Lokad-Kunden in den sicheren Rechenzentren von Microsoft Azure gespeichert sind - einem Ort, zu dem Lokad keinen physischen Zugang 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äre Kontonummer (PAN) nur gespeichert, wenn dies für legitime Geschäftszwecke unbedingt erforderlich ist?
Lokad empfängt, speichert oder verwaltet keine PANs von Kunden.
Die PAN (Primäre Kontonummer) bezieht sich in der Regel auf die Hauptnummer auf einer Kreditkarte oder Debitkarte. Es handelt sich um die auf der Vorderseite einer Karte geprägte oder gedruckte Zahlenfolge, die 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 ist jedoch zu beachten, 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 Lokads eigene Karten -, die wir sicher verwalten, gemäß den Vorgaben der Banken selbst.
4.26 Werden unverschlüsselte Primäre Kontonummern (PANs) niemals über Endbenutzer-Kommunikationstechnologien (z. B. per E-Mail, Instant Messaging und Chat) gesendet?
Ja, unverschlüsselte PANs (Primäre Kontonummern) werden niemals über unsichere Kanäle wie E-Mail gesendet. Lokad bietet einen integrierten sicheren Kommunikationskanal auf seiner Plattform, der eine überlegene Alternative zur Übermittlung sensibler Materialien darstellt. Wir empfehlen die Verwendung dieses Kanals, wenn die Nutzung eines unsicheren Kanals ein erhebliches Geschäftsrisiko darstellt.
Hinweis: Lokad empfängt, speichert oder verwaltet ausdrücklich keine PANs von Kunden. 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 abgeschlossen und enthält dieser Vertrag Klauseln zu den Informationssicherheitsvereinbarungen des Cloud-Computing-Dienstleisters?
Ja, Lokad hat einen Enterprise Agreement (EA) mit Microsoft für Azure Cloud-Computing-Dienste abgeschlossen. Das Enterprise Agreement umfasst 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 häufig in ihren Vertragsvereinbarungen mit Unternehmenskunden wider.
Obwohl wir die spezifischen Details unserer Vertragsvereinbarung nicht öffentlich bekannt geben können, sind wir nach mehr als einem Jahrzehnt Zusammenarbeit mit Microsoft zufrieden, dass diese Vereinbarung unseren Sicherheitsanforderungen und -standards entspricht.
4.28 Sind Subunternehmer an der Verarbeitung der Kundendaten beteiligt?
Nein, Lokad vergibt die Verarbeitung von Kundendetails oder -daten nicht an Subunternehmer. In Bezug auf die Lokad-Plattform kaufen wir jedoch Computing-Ressourcen - hauptsächlich virtuelle Maschinen und Blob-Speicher - von Microsoft Azure, aber abgesehen davon sind keine Dritten an der Verarbeitung von Kundendaten beteiligt.
Was die Bereitstellung von Lokads professionellen Dienstleistungen betrifft, haben nur Vollzeitmitarbeiter von Lokad (in diesem Fall die Supply Chain Scientists) Zugriff auf Kundendetails oder -daten. Lokad hat gelegentlich ein paar Praktikanten (wenn auch viel weniger als die meisten vergleichbaren Unternehmen) für Langzeitpraktika, aber sie arbeiten unter direkter und strenger 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 zur Verfügung. Zu diesem Zeitpunkt können diese Protokolle vom Lokad-Support angefordert werden. Die Protokollextraktion wird im Lokad-Konto an einem Ort platziert, der nur für Benutzer mit der Bezeichnung “Owner” zugänglich ist. Wir planen die Einführung einer direkteren Zugriffsmethode - über eine dedizierte Web-Schnittstelle - auf den bereits vorhandenen vollständigen Prüfpfad im Backend der Lokad-Plattform.
5.2 Zentralisieren Sie die Protokolle aller Komponenten in der Lösung?
Ja. Das Event Sourcing-Design von Lokad zentralisiert nicht nur die Protokolle, sondern auch alle Zustandsänderungen, die in der Lösung auftreten. Die Protokolle werden zusammen mit anderen Zustandsänderungen zentralisiert und in einer kleinen Sammlung von Ereignisströmen verwaltet, 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 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 ist.
5.3 Protokollieren Sie Änderungen und Vorgänge, die in der Anwendung durchgeführt werden? Verfolgen Sie alle Transaktionen?
Ja. Aufgrund des Event Sourcing-Designs von Lokad wird aus Notwendigkeit alles protokolliert. Tatsächlich ist die Lösung selbst die Summe der in der Lösung aufgezeichneten Ereignisse. Das Protokollieren ist daher ein grundlegender Aspekt der Architektur der Lösung. Dieses Event Sourcing-Design verhindert das versehentliche Auslassen eines Protokolls, das eine Zustandsänderung widerspiegelt. Unter einem solchen Event Sourcing-Framework gibt es keine Transaktionen, zumindest nicht im üblichen Sinne einer transaktionalen Datenbank (z. B. MySQL, Oracle usw.). Diese Transaktionen werden durch Ereignisse ersetzt, die alle Informationen enthalten, die mit einer Zustandsänderung verbunden sind.
5.4 Normalisieren Sie die Protokollformate der verschiedenen Komponenten zu forensischen Zwecken?
Ja. Die “Protokolle” sind aus auditiven und/oder sicherheitstechnischen Gesichtspunkten 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, Zahlenformate 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 Hat die Lösung die Möglichkeit, den Zustand der verschiedenen Komponenten/Dienste in Echtzeit zu überwachen?
Ja. Unsere Teilsysteme wurden mit Überwachungsendpunkten entwickelt, die speziell für Health Checks vorgesehen sind. Wir verfügen über Überwachungstools, die nur den Engineering-Teams von Lokad - ab Januar 2023 - zugänglich sind und die Informationen konsolidieren, die von diesen Überwachungsendpunkten zur Verfügung gestellt werden.
Wie bereits erwähnt, ist “in Echtzeit” bei verteilten Systemen recht vage. Für die Überwachung der Systemgesundheit liegt die erwartete Latenz im Bereich von wenigen Sekunden bis etwa einer Minute.
5.7 Hat die Lösung die Möglichkeit, Monitoring-Tools von Drittanbietern zu integrieren? Unterstützt die Lösung SNMP oder JMX oder die Möglichkeit, SNMP- und JMX-Ereignisse an Monitoring-Lösungen von Drittanbietern zu senden?
Ja, unter der Voraussetzung einer dedizierten vertraglichen Vereinbarung.
5.8 Hat die Lösung die Möglichkeit, 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 Web-Benutzeroberfläche konfiguriert werden, um einen Zeitplan und einen Ausführungszeitrahmen für eine beliebige Job-Sequenz anzugeben.
5.9 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 Client/Lokad darüber informieren, dass eine laufende Ausführungssequenz sich verzögert. Die Warnung 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 proaktive Maßnahmen zu ergreifen. Obwohl die Lokad-Plattform diese Funktion bietet, ist es immer noch erforderlich, dass ein Ingenieur die tatsächliche Logik über Envision implementiert, da die Supply-Chain-Situationen, die als “Fehler” gelten, variieren können.
5.10 Hat die Lösung Audit-Datenretentionsfähigkeiten? Werden die Daten archiviert und in eine MIS-Datenbank zur Überprüfung der Benutzeraktivität überführt?
Ja. Durch ihr Event-Sourcing-Design bewahrt die Lokad-Lösung eine umfangreiche Audit-Trail auf, der weit über das hinausgeht, was durch gängigere Designs erreicht wird, die in der Regel eine transaktionale Datenbank anstelle eines Event-Stores verwenden. Die Lokad-Lösung isoliert kein Management Information System (MIS) als separates Subsystem. Tatsächlich ist der Ereignisstrom der Audit-Trail. Allgemein gesprochen behält Lokad die Produktionsdaten für die Dauer des Dienstes beim Kunden. Bei Beendigung des Dienstes, abhängig von den vereinbarten vertraglichen Bedingungen, werden die Kundendaten gelöscht, obwohl die endgültige Löschung im Backup-System einige Monate nach Vertragsende erfolgen kann.
5.11 Hat die Lösung einen Selbstüberwachungsmechanismus (technisch und funktional) integriert?
Ja, die Lokad-Plattform integriert mehrere Selbstüberwachungsmechanismen auf verschiedenen Ebenen.
Die cloud-basierte Plattform wird von den Software-Engineering-Teams von Lokad überwacht. Da die Lokad-Plattform mehrmandantenfähig ist, erfolgt diese Überwachung weitgehend mit einer “System”-Mentalität, um sicherzustellen, dass die Fähigkeiten der Plattform (einschließlich ihres Leistungsprofils) den Standards entsprechen. Wir haben unsere eigene Instrumentierungsebene für diesen Zweck entwickelt. Das “funktionale” Monitoring ist in der Regel kundenspezifisch, da es von den Besonderheiten der jeweiligen Supply Chain abhängt. Dieses Monitoring wird in der Regel von den Teams der Supply Chain Scientists (den von Lokad bereitgestellten Ingenieuren) gemäß vertraglicher Vereinbarung durchgeführt.
Lokads Supply Chain Scientists spezialisieren sich in der Regel auf eine bestimmte Klasse von Kundenkonten (z. B. Luft- und Raumfahrt). Sie erstellen maßgeschneiderte Überwachungsinstrumente mit Hilfe des Lokad-Kontos. Dieses Monitoring umfasst die Überprüfung, ob die von Lokad gelieferten Zahlen nicht nur technisch korrekt sind, sondern auch aus der Geschäftsperspektive des Kunden.
5.12 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 Logging und Monitoring 5.2.
5.13 Werden Log-Management-Systeme von Personen verwaltet, die nicht in die Verwaltung der anderen Systeme involviert sind (d. h. Trennung der Aufgaben)?
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.14 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.15 Gibt es einen definierten Prozess für die regelmäßige Überprüfung der effektiven Firewall-Regeln?
Ja, unsere Produktionsmaschine verfügt über sehr strenge Regeln, wie z. B. das Öffnen einer sehr begrenzten Anzahl von Ports (konfiguriert über Microsoft Azure). Die Konfiguration unserer Infrastruktur erfolgt skriptgesteuert, und ihre Weiterentwicklung erfolgt gemäß unserem üblichen Code-Review-Prozess. Diese Praxis erleichtert nicht nur regelmäßige Überprüfungen, sondern verringert auch die Notwendigkeit einer manuellen Überprüfung der Regeln.
5.16 Ist das Netzwerk mit IDS (Intrusion Detection System)-Technologie ausgestattet?
Nein. IDS ist ein inhärent gefährliches Design, da es gegen das Sicherheitsprinzip des “geringsten Privilegs” verstößt: Eine Komponente erhält enorme Privilegien, um als “Man in the Middle” zu agieren. Dadurch wird das IDS selbst zu einem Hauptziel für Angreifer und erweitert die Angriffsfläche der Plattform erheblich. Lokad überwacht jedoch den Webverkehr und abnormales Benutzerverhalten auf unserer eigenen Plattform genau. Diese Funktionen sind jedoch Teil der Plattform selbst und werden daher nicht an privilegierte isolierte Softwarekomponenten von Drittanbietern delegiert.
Siehe auch Mitarbeiter 6.6.
6. Mitarbeiter
6.1 Haben Mitarbeiter NDAs (Non-Disclosure Agreements)?
Ja, alle Lokad-Mitarbeiter unterliegen einer Geheimhaltungsvereinbarung in ihren Arbeitsverträgen.
6.2 Werden Mitarbeiter in Sicherheitsbewusstsein und Sicherheit geschult?
Ja, Mitarbeitern von Lokad, die mit vertraulichen Daten und/oder Engineering-Systemen in Kontakt stehen, wird Sicherheitsbewusstsein und Sicherheitstraining vermittelt. 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 haben je nach ihren Zugriffsrechten, die innerhalb des Lokad-Kontos konfiguriert sind, Zugriff auf verschiedene Klassen der Kundendaten. Es gibt eine Webanwendung innerhalb der Lokad-Lösung, die der Verwaltung von Berechtigungen gewidmet ist (namens “Hub”).
6.4 Wie sichern Sie die Mitarbeiterarbeitsplätze?
Mit Ausnahme des Softwareentwicklungsteams arbeiten Lokad-Mitarbeiter ohne Administratorrechte auf ihren firmeneigenen Geräten. Alle Arbeitsplätze sind mit Vollplattenverschlüsselung konfiguriert, um vor Datenverlust durch Verlust, Diebstahl oder Vertrauen in Dritte (z. B. für Reparaturen) zu schützen.
Die von unseren Mitarbeitern verwendeten Arbeitsplätze enthalten keine Kundendaten. Je nach Aufgabe kann ein Mitarbeiter einige Excel-Tabellen auf seinen Computer herunterladen - zum Beispiel für eine Präsentation - aber unsere Richtlinie ist es, alle Kundendaten strikt in der Cloud zu sichern.
6.5 Wie sichern Sie Mitarbeiter-Smartphones?
Lokad-Mitarbeiter haben keine firmeneigenen Smartphones. Nicht kritische Daten wie Kalendererinnerungen können über persönliche (nicht firmeneigene) Geräte übertragen werden, aber Smartphones enthalten wie Arbeitsplätze keine Kundendaten.
6.6 Verwenden Sie ein Antivirenprogramm?
Ja, unsere Arbeitsplätze verfügen über Microsoft Defender gemäß den Microsoft Windows 10+ -Einstellungen. Wir haben kein anderes Antivirenprogramm neben Microsoft Defender, aber unsere Haltung ist, dass diese Art von Tool eher mehr Schaden als Nutzen (in Bezug auf die Computersicherheit) anrichtet. Als beispielhafter Beweis gilt der SolarWinds-Hack von 2020, der als eine der größten Computersicherheitskatastrophen aller Zeiten gilt und durch eine Software verursacht wurde, die die Sicherheit verbessern sollte. Im Allgemeinen erfordern nahezu alle für Sicherheitszwecke vorgesehenen Softwareprodukte recht hohe Systemprivilegien. Dadurch werden diese Softwareprodukte zu eigenen Angriffsvektoren. Unsere Sichtweise zur Computersicherheit ist, dass weniger mehr ist und dass das Hinzufügen sehr komplexer Technologien in unsere Anwendungslandschaft diese fast immer unsicherer und nicht sicherer macht.
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 Entwurfsphase zu beseitigen. Siehe auch Mitarbeiter 6.2. L7 ### 6.8 Enthalten alle Verträge mit Subunternehmern/externen Mitarbeitern von Lokad eine Geheimhaltungsvereinbarung (NDA)? Deckt diese NDA Kundendaten ab? {#nda}
Ja, beides trifft zu, obwohl Lokad zum Zeitpunkt der Erstellung dieses Textes nicht auf Subunternehmer/externe Mitarbeiter angewiesen ist. Die Softwareentwicklungs- 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 Meinung wäre, dass es notwendig ist, mit einem Subunternehmer zusammenzuarbeiten, würden diese den gleichen IP (Intellectual Property)- und NDA-Bedingungen wie unsere festangestellten Mitarbeiter unterliegen. Diese Vereinbarungen enthalten Bestimmungen bezüglich Informationen über Lokads Kunden.
6.9 Hat das gesamte externe Personal von Lokad eine interne Informations- und Sicherheitseinweisung von Lokad erhalten (sowie laufende relevante Schulungen)?
Lokad - zum Zeitpunkt der Erstellung dieses Textes - ist nicht auf Subunternehmer/externes Personal angewiesen. Die Softwareentwicklungs- 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 Meinung wäre, dass es notwendig ist, mit einem externen Personal zusammenzuarbeiten, wäre dies eine Voraussetzung. Alle Subunternehmer/externen Mitarbeiter würden den gleichen Sicherheitsprozessen und Schulungsanforderungen wie unsere festangestellten Mitarbeiter unterliegen.
Wie bereits erwähnt, ist Lokad derzeit nicht auf externes Personal angewiesen, daher findet eine solche Schulung nicht statt.
Siehe auch Mitarbeiter 6.8
6.10 Enthalten alle Verträge mit Unternehmen, die das externe Personal von Lokad bereitstellen (alle Auftragnehmer, Berater usw., die an der Erbringung von Lokads Dienstleistungen beteiligt sind), die Anforderung, dass die externen Mitarbeiter durch Hintergrundüberprüfungen überprüft werden? Entspricht diese Hintergrundüberprüfung dem entsprechenden Zugriffslevel auf Informationen und der Bedeutung der Rolle des Mitarbeiters?
Lokad - zum Zeitpunkt der Erstellung dieses Textes - ist nicht auf Subunternehmer/externes Personal angewiesen. Die Softwareentwicklungs- 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 Meinung wäre, dass es notwendig ist, mit einem externen Personal zusammenzuarbeiten, wäre dies eine Voraussetzung. Alle Subunternehmer/externen Mitarbeiter würden den gleichen Sicherheitsprozessen, Hintergrundüberprüfungen und Schulungsanforderungen wie unsere festangestellten Mitarbeiter unterliegen.
Hinweis: Historisch gesehen werden viele der größten - und schlimmsten - Vorfälle wie Cyber-Spionage von Personen begangen, die einwandfreie Aufzeichnungen haben. Aus diesem und anderen Gründen zögert Lokad, sich auf externes Personal zu verlassen, und bevorzugt stattdessen direkte, unbefristete Arbeitsverträge.
6.11 Werden die Administratorkonten am Ende des Beschäftigungsverhältnisses automatisch deaktiviert oder gelöscht?
Ja. Alle Lokad-Mitarbeiter erhalten ihre Zugriffsrechte über einen föderierten Identitätsanbieter (Microsoft Azure Active Directory). Am Ende ihrer Beschäftigung wird ihnen bei Bedarf der Zugriff entzogen, wodurch automatisch alle zugehörigen Administrationsrechte deaktiviert werden.
Hinweis: Den meisten Lokad-Mitarbeitern werden keine Administrationsrechte gewährt, da diese für die Ausführung ihrer Aufgaben nicht erforderlich sind.
6.12 Führen Sie Strafregisterüberprüfungen bei allen Mitarbeitern durch, die Zugriff auf sensible Daten, Finanzdaten, Bankdaten, Zahlungskartendaten usw. haben?
Ja, Strafregisterüberprüfungen werden streng gemäß den Anforderungen der jeweiligen Tätigkeit durchgeführt.
Es sollte beachtet werden, dass Lokad keine Zahlungskartendaten intern verwaltet - dies wird von Dritten verwaltet. Daher haben 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 arbeitet Lokad in einem 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 Räumlichkeiten von Lokad über eigene sichere Zugangspunkte, die unabhängig von denen des Gebäudes selbst sind. Diese letzte Ebene verhindert, dass Mitarbeiter anderer Unternehmen im Gebäude Zugang zu den Büros von Lokad erhalten.
Hinweis: Außergewöhnliche Besucher (wie Kunden, potenzielle Kandidaten usw.) müssen von Mitarbeitern von Lokad persönlich begrüßt und zum Eintritt berechtigt werden.
6.14 Sind Besucher in der Einrichtung zugelassen?
Wenn “Einrichtung” “der Ort, an dem Kundendaten gespeichert und verarbeitet werden” bedeutet, 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 seiner Unternehmenszentrale. Unsere Büros sind nicht öffentlich zugänglich, aber es gibt gelegentlich außergewöhnliche Umstände, wie z.B. Besuche von Kunden, Bewerbern, 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 von Mitarbeitern von Lokad begleitet.
6.15 Werden Papierdatensätze (und abnehmbare elektronische Medien mit Daten) über Nacht in sicheren feuerfesten Schränken aufbewahrt?
Lokad arbeitet nicht mit Papierdatensätzen und auch nicht mit abnehmbaren elektronischen Medien. Da wir keine physischen Aufzeichnungen zur Aufbewahrung haben, hat Lokad keinen Bedarf an feuerfesten Schränken. L12 Obwohl wir gelegentlich ein Dokument ausdrucken 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 auszudrucken, aber wenn es theoretisch erforderlich wäre, ist unsere Standardrichtlinie auch, 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 aus rechtlichen Gründen drucken müssen, oder gelegentlicher Dokumente, die aus Notwendigkeit gedruckt werden (z.B. ein Poster für eine Messe, obwohl auch dies in der Regel ausgelagert wird), ist die Arbeitsumgebung von Lokad streng digital.
Am Ende des Tages hat Lokads Mitarbeiter nichts zu “klären”. Sobald die Computersitzung des Mitarbeiters gesperrt wurde - eine Richtlinie, die wir strikt durchsetzen - ist der entsprechende Schreibtisch effektiv geräumt.
6.17 Wo kommen Faxe an und wer hat Zugriff darauf?
Lokad hat noch nie ein Faxgerät - sei es physisch oder virtuell - besessen. Wir kennen keinen zwingenden Anwendungsfall, der unsere Haltung zu dieser Technologie ändern würde.
6.18 Gibt es einen Prozess zur Überprüfung der Rückgabe von Bestandteilen (Computer, Mobiltelefone, Zugangskarten, Token, Smartcards, Schlüssel usw.) bei Beendigung des Arbeitsverhältnisses?
Ja, wir haben nicht nur einen Prozess, sondern auch eine IT-Asset-Management-Software, um diese Bemühungen zu unterstützen und die Anzahl der Verwaltungsfehler zu minimieren.
Wir haben jedoch bewusst die Sicherheit von Lokad so konzipiert, dass sie nicht von der rechtzeitigen Rückgabe von Bestandteilen 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 auch sein mögen. In der Praxis kommt dies sehr selten vor, aber aus technischer Sicht gehen wir von der gegenteiligen Annahme aus. Aus diesem Grund können Bestandteile remote deaktiviert werden. Darüber hinaus wenden wir immer eine vollständige Laufwerksverschlüsselung an, wenn dies möglich ist.
Allgemein gesagt wurde unsere Arbeitsumgebung so konzipiert, dass keine dauerhafte Speicherung von Kundendaten auf Arbeitsstationen, Notebooks oder Mobiltelefonen erforderlich ist. Dieses Design verringert die Bedeutung der Bestandteile erheblich, falls unsere anderen präventiven Maßnahmen versagen sollten.
6.19 Sind die Personalrichtlinien und/oder -verfahren von der Geschäftsleitung genehmigt und den Betroffenen mitgeteilt, und ist ein Verantwortlicher benannt, der für deren Aufrechterhaltung und Überprüfung zuständig ist?
Ja, unsere Personalrichtlinien und -verfahren wurden formell von der Geschäftsleitung genehmigt. Wir legen großen Wert auf klare Kommunikation, und daher wurden diese Richtlinien und Verfahren umfassend an alle relevanten Beteiligten verbreitet, um ein vollständiges Verständnis und eine Einhaltung sicherzustellen.
Darüber hinaus haben wir einen Verantwortlichen benannt, der für die laufende Pflege, Aktualisierung und regelmäßige Überprüfung der Richtlinien und Verfahren verantwortlich ist. Dadurch stellen wir sicher, dass unsere Praktiken aktuell, relevant und in Übereinstimmung mit branchenüblichen Standards und unseren Unternehmenszielen bleiben.
6.20 Werden von Personen, die mit Ihrer Organisation in Verbindung stehen, persönliche (BYOD) Mobilgeräte verwendet, die Zugriff auf Kundendaten haben?
Nein, Lokad erlaubt keinen Zugriff auf Kundendaten auf persönlichen (BYOD) Mobilgeräten. Wir stellen unseren Mitarbeitern hochwertige, firmeneigene Hardware zur Verfügung, um den Bedarf an persönlichen Geräten zu eliminieren. Diese Regelung bezieht sich auf das häufige Szenario, dass Mitarbeiter aufgrund von Unzufriedenheit mit minderwertiger Unternehmenshardware ihre eigenen Geräte verwenden.
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 cloudbasierten Plattform. Auf Mitarbeitergeräten werden Kundendaten (falls überhaupt abgerufen) nur vorübergehend und nur in minimalen Segmenten verarbeitet, um maximale Sicherheit zu gewährleisten.
Anmerkungen
L11
Generell wurde unsere Arbeitsumgebung so konzipiert, dass keine dauerhafte Speicherung von Kundendaten auf Arbeitsstationen, Notebooks oder Mobiltelefonen erforderlich ist. Dieses Design verringert erheblich die Kritikalität der Bestandteile im Falle eines Versagens unserer anderen präventiven Maßnahmen.
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 cloudbasierten Plattform. Auf Mitarbeitergeräten werden Kundendaten (falls überhaupt abgerufen) nur vorübergehend und nur in minimalen Segmenten verarbeitet, um maximale Sicherheit zu gewährleisten.
Anmerkungen
-
In der Videospielindustrie sind viele, wenn nicht die meisten Mitarbeiter wirklich leidenschaftlich für Videospiele; nicht nur für diejenigen, die zufällig 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 von Mitarbeitern von Unternehmenssoftware, offen gesagt, immense Langeweile. Es ist ein Kampf, Menschen dazu zu bringen, sich für ein Stück Unternehmenssoftware zu interessieren, aber ein notwendiger Kampf. ↩︎
-
Prognosetechnologien, eine Schlüsselkomponente von Lösungen zur Optimierung der Supply Chain, sind besonders anfällig für spektakuläre Ü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 beeinträchtigt die Software nicht durch Code, sondern durch die Verbreitung falscher oder schädlicher Überzeugungen unter den Spezialisten, die die Entwicklung der Software steuern. Siehe Adversariale Marktforschung für Unternehmenssoftware ↩︎
-
Selbst die zuverlässigsten Menschen sind gelegentlich erschöpft, krank oder gestresst. Das alte Sprichwort besagt, dass jedes (Computer-)System, das auf menschliche Zuverlässigkeit angewiesen ist, unzuverlässig ist. ↩︎