Data Obfuscation in Splunk Enterprise
•
3 likes•2,139 views
Daten anonymisieren und pseudonymisieren mit Splunk Es gibt unterschiedlichste Gründe, warum Maschinendaten vor unberechtigten Zugriffen geschützt werden sollten. Interne und Externe Compliance Vorgaben sowie "Privacy by Design" Strategien zur Verbesserung der Sicherheit oder als Teil einer Risiko-Minimierungsstrategie werden für Unternehmen im Big Data Bereich immer wichtiger. In dieser Session erfahren Sie, wie Sie Ihre Maschinendaten auf unterschiedlichen Ebenen schützen: in Motion: sichern Sie die Verbindungen von und zu Splunk Enterprise ab Datenintegrität: stellen Sie die Datenintegrität der in Splunk gespeicherten Daten sicher At Rest: verschlüsseln Sie alle Daten, die Splunk auf Disk schreibt Einzelne sensible Felder in Ihren Maschinendaten anonymisieren / pseudonymisieren
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Data Obfuscation in Splunk Enterprise
Similar to Data Obfuscation in Splunk Enterprise (20)
More from Splunk
More from Splunk (20)
Recently uploaded
Recently uploaded (20)
Data Obfuscation in Splunk Enterprise
- 1. Copyright © 2015 Splunk Inc. Data Obfuscation in Splunk Enterprise
- 2. 2 Agenda The Drivers Data-in-Flight Data-at-Rest Data Obfuscation within Splunk Enterprise – Anonymization – Pseudonymization Summing Up Demonstration
- 3. 3 Agenda The Drivers Data-in-Flight Data-at-Rest Data Obfuscation within Splunk Enterprise – Anonymization – Pseudonymization Summing Up Demonstration
- 5. 5 The Drivers Stakeholder* Workers Council Data Privacy Officer GDPR Privacy Shield PCI …. Requirements* Anonymization Pseudonymization Pseudonymization Encryption RAW Event archival for 1 year – 3 month online *Examples only | Your legal department will assist you.
- 6. 6 The Drivers Stakeholder* Workers Council Data Privacy Officer GDPR Privacy Shield PCI …. Requirements* Anonymization Pseudonymization Pseudonymization Encryption RAW Event archival for 1 year – 3 month online You need to ensure to have a flexible platform that fits your needs – even if they change! *Examples only | Your legal department will assist you.
- 7. 7 Spoilt for Choice What – Confidentiality / Integrity / Authenticity Where – At Source / In Flight / At Rest / Presentation Layer How – Anonymization / Pseudonymization Usability, Maintainability, Cost, …
- 9. 9 Data-in-Flight Encryption and/or authentication using your own certificates for: – Communications between the browser and Splunk Web – Communication from Splunk forwarders to indexers – Other types of communication, such as communications between Splunk instances over the management port Type of exchange Client function Server function Encryption Certificate Authentication Common Name checking Type of data exchanged Browser to Splunk Web Browser Splunk Web NOT enabled by default dictated by client (browser) dictated by client (browser) search term results Inter-Splunk communication Splunk Web splunkd enabled by default NOT enabled by default NOT enabled by default search term results Forwarding splunkd as a forwarder splunkd as an indexer NOT enabled by default NOT enabled by default NOT enabled by default data to be indexed Deployment server to indexers splunkd as a forwarder splunkd as an indexer NOT enabled by default NOT enabled by default NOT enabled by default Not recommended. Use Pass4SymmKey instead. http://docs.splunk.com/Documentation/Splunk/latest/Security/AboutsecuringyourSplunkconfigurationwithSSL
- 10. Data-at-Rest
- 11. 11 Integrity Compute SHA256 hash for every slice in hot bucket When bucket rolls from hot to warm, create SHA256 hash of the file containing the hashes of the individual slices Can verify integrity from the CLI Enable for an entire index http://docs.splunk.com/Documentation/Splunk/latest/Security/Dataintegritycontrol http://blogs.splunk.com/2015/10/28/data-integrity-is-back-baby/
- 12. 12 Encryption Encryption of all data Splunk writes to disk (index, raw data, metadata) Pros: – Easy to implement with OS or device means – Covers all data – Transparent to Splunk Cons: – Limited granularity – Performance overhead – Limited security against rogue users
- 14. Data Obfuscation in Splunk Enterprise
- 15. 15 What is Anonymization? Anonymization of data means processing it with the aim of irreversibly preventing the identification of the individual to whom it relates. 2016-12-24 09:00 host1 mm28522 login successful 2016-12-24 09:00 host1 ****** login successful
- 16. 16 What is Pseudonymization? Pseudonymization of data means replacing any identifying characteristics of data with a pseudonym, or, in other words, a value which does not allow the data subject to be directly identified. 2016-12-24 09:00 host1 mm28522 login successful 2016-12-24 09:00 host1 0fc43cd589ec74ddb677501adf6c295b login successful
- 17. Anonymization
- 18. 19 At Indexing Time Used SEDCMD or TRANSFORMS at indexing time Pros: – Easy to implement and maintain, easy usability, low complexity – No impact on licensing Cons: – Modifies raw events – Anonymization -> less information available https://docs.splunk.com/Documentation/Splunk/latest/Data/Anonymizedata
- 19. Pseudonymization
- 20. 21 Presentation Layer Hide data at presentation layer Locked down User – Pre-defined App with dashboard access only – No search app, no raw search, no raw event drill down | eval username = “****” | eval username=sha256(username) or use your own custom search command
- 21. 22 Application Layer Data pseudonymization before Splunk picks it up Pros: – Managed earliest as possible in the process – Data source owner responsible – Data-Privacy challenge solved for data stored on source as well Cons: – Individual solution per data source/type/method required
- 22. 23 Event Duplication Duplicate event, store original event and pseudonymized event in separate indexes Pros: – Easy to implement and maintain, easy usability, low complexity Cons: – Storage costs (can be limited with tsidx retention but slower search) – License costs idx_cleartext idx_pseudonym
- 23. 24 Summary Index Scheduled summary search transforms the data and stores it in a new summary index Pros: – Summary index does not count against license – Everything GUI managed – Allows grouped aggregation (anonymization, too) Cons: – Regular search utilizing resources – Breaks out-of-the-box CIM (source=search name, sourcetype=stash, original sourcetype moved to orig_sourcetype) idx_cleartext idx_summary
- 24. 25 Input Layer Data de-centralized piped through a custom method using a modular input Pros: – High flexibility on encryption, hashing etc. methods and requirements – Processing can be done decentralized at each forwarder to distribute processing load Cons: – Scripting required for modular inputs
- 25. 26 Summing Up Many possible ways – each has pros and cons Anonymization – Data aggregation might be an additional layer as specific access to a specific file from a specific host does potentially allow identification back to an individual Pseudonymization – Requires a proper concept to ensure the pros and cons are known and accepted in advance such that impact and additional complexity is understood in production and operation use We are transparent on possibilities, allow multiple ways and levels which are available for data obfuscation.
- 26. Demonstration
- 27. 28 Demo Scenario Encryption Modular Input Log file with sensitive data Read log file data File Monitor input (UF) Modular Input encrypts field values Data sent and stored Decryption Custom Search Command Events in Splunk with encrypted field values User is authorized to use custom search command Custom search command Decrypts fields Anonymization SEDCMD Log file with sensitive data Read log file data File Monitor Input (UF) Pipeline Apply SEDCMD and replace data Data stored
- 30. 31 Protocol Data Input Different input protocols Custom data handler allows to pre-process data – Polyglot: many programming languages can be used. E.g. Java, JavaScript, Python, … Different output protocols Data Handler https://splunkbase.splunk.com/app/1901/
- 31. 32 Log File cleartext.log Field Description Action we want to take first First name Encrypt with AES name Last Name Encrypt with AES dob Date of Birth Encrypt with AES uid Employee ID Anonymize
- 33. 34 IDX Anonymization SEDCMD (props.conf)
- 34. 35 Create PDI Custom Data Handler
- 35. 36 Receiver – Protocol Data Input
- 36. 37 PDI Configuation – Protocols
- 37. 38 PDI Configuration – Data Handler Parameters for custom data handler: • regex: identify fields to encrypt • *_Key_File: Keys to use to encrypt PDI Custom data handler (here: Java)
- 39. 40 Decrypt Data – Custom Search Command
- 40. Thank You
Editor's Notes
- Auch hier können wir im Presentation Layer tätig werden und zum Beispiel einen Benutzernamen durch einen Hash ersetzen oder ein eigenes Custom Search Command verwenden. Wie bei der Anonymisierung ist dies nur sinnvoll, wenn gleichzeitig die Möglichkeiten des Benutzers weiter eingeschränkt werden.
- Unser Thema ist heute, wie sich Daten in einer Splunk-Umgebung verschleiern lassen, so dass nur berechtigte Personen Kenntnis von ihnen erlangen. Als Teilnehmer dieser Veranstaltung sind wir alle berechtigt, die heutige Agenda zu sehen. Daher entferne ich den Schleier jetzt.
- Die Frage ist sehr allgemein gestellt. Daher treten wir zunächst einen Schritt zurück und schauen uns an, welchen Hintergrund die Fragestellung hat und was üblicherweise mit einer Antwort erreicht werden soll. Eine Antwort erfordert häufig ein Vorgehen auf verschiedenen Ebenen. Daher betrachten wir zunächst allgemein die Datensicherheit bei der Übertragung und Speicherung von Daten in Splunk und kommen dann zur Verschleierung mit Splunk.
- Die Frage nach der Verschleierung von Daten taucht immer wieder auf. Ausgangspunkt hierfür sind dabei meist Anforderungen, die an den Schutz von Daten gestellt werden. Diese Anforderungen wiederum haben ihren Ursprung in internen oder externen Regularien, die sich auf die Erfassung, Verarbeitung und Speicherung von Daten beziehen. Ziel ist es, das Risiko zu minimieren, dass Daten Unberechtigten zur Kenntnis gelangen.
- Innerhalb eines Unternehmens sind mehrere Personen und Gruppen mit dem Thema Datenschutz befasst und jede dieser Gruppen hat eigene Vorstellungen und Anforderungen. So ist es denkbar, dass zum Beispiel der Betriebsrat gewisse Daten anonymisieren möchte, während einer anderen Gruppe eine Pseudonymisierung ausreicht. Die anzuwendenden Regularien selbst sind nicht Teil der heutigen Präsentation. Aber Anonymisierung und Pseudonymisierung sind technische Maßnahmen des Datenschutzes, die im Rahmen der Umsetzung von Regularien von Interesse sein können. Und wir wollen uns heute anschauen, wie diese technischen Maßnahmen in Splunk abgebildet werden können.
- Aufgrund der unterschiedlichen Anforderungen, Interessen aber auch Datenquellen und -typen, ist jede Lösung individuell. Und somit sollte eine Plattform zum Einsatz kommen, die möglichst flexibel ist und so auf unterschiedliche und sich ändernde Anforderungen reagieren kann. Und Splunk ist eine solche flexible Plattform.
- Auf der Suche nach eine Lösung für die gestellten Anforderungen sind diverse Entscheidungen zu treffen und man hat die Qual der Wahl. Wenn wir über Datenschutz reden, so haben wir es mit den üblichen Schutzzielen zu tun: Vertraulichkeit, Integrität und Authentizität. Zusätzlich muss man sich fragen, auf welcher Ebene man ansetzen kann und möchte. Beispiele wären hier die Datenquelle, Datenübertragung, Datenspeicherung oder auch die Darstellungsebene. Und schließlich die Frage, welche Methoden man überhaupt anwenden möchte, um die gesetzten Ziele zu erreichen. Das ganze natürlich unter Berücksichtigung von Randbedingungen in Bezug auf Umsetzbarkeit, Nutzbarkeit, Pflegbarkeit und natürlich auch Kosten.
- Beginnen wir der Datenübertragung in Splunk.
- Splunk erlaubt es, für die Kommunikation zwischen den einzelnen Komponenten TLS/SSL einzusetzen und so die drei genannten Schutzziele Vertraulichkeit, Integrität und Authentizität zu erreichen.
- Als nächstes die Datenspeicherung.
- Bei gespeicherten Daten stellt sich zum einen die Frage, wie man erkennen kann, ob sie nach der initialen Speicherung verändert worden sind. Dabei kann es sich um das berühmte gekippte Bit handeln aber auch um eine Veränderung, die von einem Benutzer versehentlich oder absichtlich durchgeführt wurde. Splunk bietet hier die sogenannte Data Integrity Control. Dabei werden für Slices in Hot Buckets eine Indexes SHA-256 Hashes erzeugt und in einer Datei abgespeichert. Wenn die Buckets in den Status „warm“ wechseln, wird zusätzlich eine Checksumme von der Datei mit den Hashes erzeugt und abgelegt. Über die Kommandozeile und den Befehl splunk check-integrity kann dann die Integrität der Slices überprüft werden.
- Um Vertraulichkeit zu erreichen, kann man darüber nachdenken, all Daten, die von Splunk gespeichert werden, zu verschlüsseln. Viele Speichersysteme aber auch Dateisysteme bieten eine solche Möglichkeit, die einige Vorteile hat: Sie ist leicht umsetzbar Es lassen sich alle Daten verschlüsseln Verschlüsselung / Entschlüsselung ist transparent für Splunk und erfordert keine Anpassungen Wie üblich hat diese Methode auch ihre Schattenseiten: Die Granularität ist meist auf ganze Dateisysteme oder LUNs beschränkt Verschlüsselung auf Betriebssystemebene kann Einfluss auf die Systemperformance haben Da Verschlüsselung transparent für die Anwendung ist, bietet sie nur Schutz gegen ausgewählte Bedrohungen wie den Diebstahl eines Speichermediums. Wer Zugang zum System zur Laufzeit hat, kann auf Daten im Klartext zugreifen.
- Hier können zusätzliche Tools helfen, die eine erweiterte Zugriffskontrolle bei transparenter Verschlüsselung bieten, wie zum Beispiel Vormetric Transparent Encryption. Aber das ist ein eigenes Thema.
- Wie können wir jetzt Daten in Splunk verschleiern? Ich habe zuvor schon mehrfach die Begriffe Anonymisierung und Pseudonymisierung verwendet, aber deren Bedeutung noch nicht erklärt. Das soll jetzt nachgeholt werden.
- Bei der Anonymisierung von Daten geht es darum ein Datum so zu verändern, dass das Original nicht wiederhergestellt werden kann. Meist geht es dabei um die Anonymisierung von Angaben über eine bestimmte Person. Nach der Anonymisierung ist nicht mehr feststellbar, zu welcher Person die Daten gehören. In diesem Beispiel wird der Benutzername mm28522 durch ****** ersetzt. Wir sehen hier auch schon, dass die Anonymisierung von Daten Einfluss darauf hat, welche Informationen wir aus den Daten ziehen können. Eine Statistik über die Anzahl der Anmeldeversuche pro Benutzernamen ist zum Beispiel nicht mehr möglich.
- Bei der Pseudonymisierung werden Daten durch ein Pseudonym ersetzt, also durch etwas, was es nicht direkt erlaubt, die zugehörige Person zu identifizieren. Eine Identifizierung ist aber mit Hilfsmitteln möglich. Ein solches Hilfsmittel kann eine Tabelle sein, die dem Pseudonym das Original zuordnet oder beim Einsatz von kryptographischen Methoden die entsprechenden Schlüssel. Auch bei der Pseudonymisierung kann es sein, dass gewissen Statistiken nicht mehr sinnvoll zu erstellen sind.
- Anonymisierung in Splunk
- Auf der rechten Seite sehen wir den Datenfluss durch Splunk. Eine Applikation liefert Daten, die über einen sogenannten Input an Splunk geschickt werden. Dann laufen die Daten durch die verschiedenen Pipelines in Splunk und werden schließlich in einem Index abgespeichert. Der Anwender greift über den Search Head auf die Daten zu und erhält eine Ansicht der Ergebnisse. Splunk bietet von Haus aus die Möglichkeit, raw Events zu modifizieren, bevor sie in einen Index geschrieben werden. Dies erfolgt über entsprechende SEDCMD oder TRANSFORMS, die in der Typing Pipeline zur Anwendung kommen. Im Beispiel werden bei einer neunstelligen Zahl, die auf ssn= folgt, die ersten fünf Stellen durch x ersetzt und dann der veränderte raw Event abgespeichert.
- Auf der rechten Seite sehen wir den Datenfluss durch Splunk. Eine Applikation liefert Daten, die über einen sogenannten Input an Splunk geschickt werden. Dann laufen die Daten durch die verschiedenen Pipelines in Splunk und werden schließlich in einem Index abgespeichert. Der Anwender greift über den Search Head auf die Daten zu und erhält eine Ansicht der Ergebnisse. Splunk bietet von Haus aus die Möglichkeit, raw Events zu modifizieren, bevor sie in einen Index geschrieben werden. Dies erfolgt über entsprechende SEDCMD oder TRANSFORMS, die in der Typing Pipeline zur Anwendung kommen. Dies ist einfach umzusetzen und zu pflegen und nicht sonderlich komplex. Andererseits werden hierdurch die raw Events vor der Speicherung verändert und wie bereits gesagt, gehen Informationen durch die Anonymisierung verloren.
- Kommen wir zur Pseudonymisierung
- Wir im Presentation Layer tätig werden und zum Beispiel einen Benutzernamen durch einen Hash ersetzen oder ein eigenes Custom Search Command verwenden. Dies ist jedoch nur sinnvoll, wenn gleichzeitig die Möglichkeiten des Benutzers weiter eingeschränkt werden.
- Am Anfang des Datenflusses steht die Applikation. Die Pseudonymisierung kann gegebenenfalls schon durchgeführt werden, bevor Splunk die Daten verarbeitet. Die Vorteile dieser Methode bestehen darin, dass die Pseudonymisierung früh im gesamten Prozess erfolgt und die Verantwortung bei den Data Ownern liegt Andererseits ist jede Applikation daraufhin zu prüfen, ob sie Daten überhaupt entsprechend zur Verfügung stellen.
- Was können wir bei den Inputs tun? Event Routing erlaubt es, Events zu duplizieren und zum Beispiel in verschiedene Indizes zu schreiben. In einem Index befinden sich pseudonymisierte Daten, im anderen Klartext. Zugriffsregeln auf die Indices regeln, welche Benutzer auf welchen Index zugreifen können. Dies ist einfach zu konfigurieren und zu pflegen. Jedoch erhöht sich das indizierte Datenvolumen, was erhöhte Lizenz- und Speicherkosten zur Folge hat. Im Speicherbereich kann tsidx Retention helfen, aber zu verlängerten Suchzeiten führen.
- Alternativ lassen sich Summary Index Searches definieren, die keine kritischen Daten enthalten. Auch hier wird der Zugriff auf den Index mit den Daten im Klartext eingeschränkt. Vorteil hier ist, dass Summary Indexe nicht gegen das täglich indizierte Datenvolumen gezählt werden. Andererseits benötigen Summary Searches Systemressourcen und die Analyse kann erschwert werden: So ändert sich der sourcetype zu „stash“ und der originäre sourcetype findet sich im Feld orig_sourcetype.
- Wenn die bisher vorgestellten Ansätze die gestellten Anforderungen nicht erfüllen, kann man auf der Ebene der Inputs ansetzen. Splunk kennt neben File Inputs, Network Inputs und Scripted Inputs die sogenannten Modular Inputs. Dies haben den Vorteil, dass sie sehr flexibel sind. Allerdings muss man das nötige Skripting bzw. die Programmierung selber durchführen. Der Splunk Add-on Builder kann hier eine Hilfe sein. Wie man einen solchen Modular Input für die Verschleierung von Daten nutzen kann, wird beispielhaft in der Demonstration gezeigt.
- Splunk bietet verschiedene Möglichkeiten, Daten zu verschleiern. Alle Ansätze haben ihre Vor- und Nachteile und es ist abzuwägen. Bei der Anonymisierung von Daten kann die Aggregation von Daten weiteren Schutz liefern. Denn auch bei anonymisierten Daten kann es anhand von anderen Informationen möglich sein, die anonymisierte Information wieder herzustellen. Wie üblich gilt es abzuwägen, welche Lösung die beste für die vorliegenden Anforderungen ist.
- Kommen wir jetzt zur Demonstration
- Die Anforderung ist mehrteilig: Wir haben einen Search Head und einen Indexer. Auf einem Universal Forwarder liegt ein Logfile vor, welches Daten enthält, die teilweise zu verschlüsseln sind. Wir wollen die zuvor beschriebene Idee umsetzen, einen Modular Input für die Pseudonymisierung der Daten zu verwenden. Dabei wollen wir den Aufwand möglichst gering halten, also möglichst viele Funktionalitäten nutzen, die bereits in Splunk vorhanden sind. Die Grundidee besteht daher darin, die Logdatei auf dem Universal Forwarder durch einen File Monitor überwachen zu lassen und die Daten dann an den Modular Input zu schicken. Berechtigte Personen sollen die Möglichkeit haben, die zuvor verschlüsselten Daten zu entschlüsseln. Dies wird über ein Custom Search Command und entsprechende Berechtigungen realisiert. Teile der Daten sind zu anonymisieren. Dies erfolgt einfach über SEDCMD.
- Aber was ist ein Modular Input und wie baut man einen? Zunächst einmal ist ein Modular Input eine weitere Möglichkeit Daten in Splunk zu erfassen. Schauen wir in die Splunk-Dokumentation zu Modular Inputs, so wird als einer der Anwendungsfälle das Reformatieren komplexer Daten genannt – also zum Beispiel Verschleierung.
- Wie üblich kann man versuchen herauszufinden, ob bereits jemand dass Problem gelöst hat. Auf Splunkbase findet an zahlreiche Beispiele für Modular Inputs.
- Die Protocol Data Inputs App hat meine besondere Aufmerksamkeit geweckt. Denn dieser Modular Input erlaubt es, Daten über verschiedene Protokolle wie TCP, UDP, HTTP entgegenzunehmen. Diese Daten werden dann von einem sogenannten Data Handler verarbeitet. Der Data Handler kann in unterschiedlichen Programmiersprachen wie Java, JavaScript, Python und weiteren erstellt werden. Die Ausgabe der Daten erfolgt dann ebenfalls über verschiedene Wege, nämlich STDOUT, TCP oder HTTP Event Collector. Eingabe und Ausgabe sind also schon erledigt und man kann sich auf die Verarbeitung der Daten konzentrieren, also die Verschlüsselung von Daten. Sieht nach einem guten Lösungsansatz für unsere Aufgabe aus!
- Hier sehen wir das Logfile. Jeder Event besteht aus einer Zeile. Am Beginn der Zeile steht der Timestamp. Die restlichen Daten liegen als Key/Value Paare vor, die durch ein & voneinander getrennt sind. Die Felder first, name, dob gelten als kritisch und sollen mit AES verschlüsselt werden. Das Feld uid soll anonymisiert werden
- Auf dem Universal Forwarder wird ein File Input definiert. Die Daten im raw Format an einen Server / Port geschickt.
- Das entsprechende SEDCMD für die Anonymisierung der uid wird auf dem Indexer in props.conf definiert.
- Jetzt ist es an der Zeit, den Data Handler für den Protocol Data Input zu erstellen.
- Anschließend muss der Der Protocol Data Input definiert und konfiguriert werden. Der PDI lauscht auf dem Port 41002, an den der UF die Daten im Raw-Format schickt.
- Daten werden über TCP Port 41002 entgegengenommen und über STDOUT ausgegeben (und landen damit in der Data Pipeline).
- Die Verarbeitung der Daten erfolgt durch den Custom Data Handler. In diesem Fall ist dies eine Java Klasse, die die eingehenden Daten mit AES verschlüsselt. Dem Custom Data Handler können Konfigurationsparameter im JSON-Format übergeben werden. Dieser Data Handler erlaubt es, über einen regulären Ausdruck zu beschreiben, welche Daten verschlüsselt werden sollen, nämlich die in der Capturing Group encrypt. Die Gruppen pre und post beschreiben Text, der in der Ausgabe vor bzw. hinter dem verschlüsselten und zusätzlich Base64 kodierten Text ausgegeben werden soll. Weitere Parameter sind zum Beispiel der Name des Key-Files.
- Wie sehen jetzt Daten aus, die vom Data Handler verarbeitet wurden? Im raw Event sehen wir die Feldnamen dob, first und name mit verschleierten Werten. Der Wert des Feldes uid ist durch den Text HIDDEN_UID ersetzt worden.
- Das Custom Search Command aesdecrypt entschlüsselt die Werte der angegebenen Felder, hier also name und first.