Seite wählen

NETWAYS Blog

OpenSearch Dashboards: TLS, Konten & Datensicherheit

von | Sep 8, 2023 |

This entry is part 2 of 5 in the series OpenSearch Security

Du hast dich auch schon gefragt, wie du die einzelnen Komponenten von OpenSearch sicher verknüpfen kannst? Dann bist du auf die gleichen Probleme gestoßen wie ich. Damit du nicht auch mehrere Tage mit der Lösungsfindung verbringen musst, habe ich meine Lösungen für dich zusammengetragen.

In diesen Blogpost gehe ich auf die Lösung folgender Probleme ein:

  • OpenSearch Dashboards sicher verwenden
  • Wie deaktiviere ich Accounts, wie füge ich neue hinzu?
  • Wie kann ich mehr aus OpenSearch Dashboards herausholen und beispielweise Powershell Befehle überwachen?

OpenSearch Indexe referenzieren, Discover testen, und Dashboards verwenden

Im Vergleich zu Elasticsearch wird das Indexmanagement in OpenSearch als „Dashboard Management“. Hier muss man via „Index Patterns“ auf den gewünschten Index für die Discover–Anzeige referenzieren, z.b. via „graylog*“

Dashboards lassen sich bequem via Visualize -> Create Visualization erstellen. Mich interessieren vor allem SSH Zugriffe und neue Nutzer Sessions.

OpenSearch Dashboards mit TLS

Im Idealfall stellst du sicher, dass die gesamte Kommunikation von OpenSearch zu den OpenSearch Dashboards über den gesamten Transportweg hinweg verschlüsselt ist. Hier werden schließlich sämtliche (auch vertrauliche) Daten ausgetauscht.
Gleichzeitig ist es wichtig, dass auch die Verbindung von deinem Browser zu den OpenSearch Dashboards verschlüsselt ist.

Um dir ein aktiv genutztes Beispiel für die Verschlüsselung zu geben, zeige ich eine von mir getestete (minimalistische) TLS-Konfiguration, die du unter „/etc/opensearch-dashboards/opensearch_dashboards.yml“ anpassen kannst.

Du siehst die Hostnamen deiner OpenSearch-Server, die genutzten Ports, Zugriffsrechte sowie die Zertifikate für den Transportweg und den Browser.
Zusätzlich benötigst du einen Zugriffsaccount. Beachte, dass teilweise standardmäßige Standardpasswörter aktiv sind. Wie du Service- und Benutzernamen änderst, erfährst du im nächsten Abschnitt.

server.name: "opensearch-dashboards"
opensearch.hosts: ["https://opensearch.lan:9200"]

opensearch.requestHeadersAllowlist: [ authorization,securitytenant ]
opensearch_security.readonly_mode.roles: [kibana_read_only]

server.ssl.enabled: true
server.ssl.certificate: /etc/opensearch-dashboards/opensearch-dashboards.crt
server.ssl.key: /etc/opensearch-dashboards/opensearch-dashboards.key

opensearch.ssl.certificate: /etc/opensearch-dashboards/opensearch-dashboards.crt
opensearch.ssl.key: /etc/opensearch-dashboards/opensearch-dashboards.key

opensearch.ssl.certificateAuthorities: [ "/etc/opensearch-dashboards/graylog-ca-root.crt" ]
opensearch.ssl.verificationMode: certificate

opensearch.username: my_dasbhboards_service_acc 
opensearch.password: my_dasbhboards_secure_pass

OpenSearch Accounts ändern via Securityadmin

Um Service-Passwörter zu verändern, musst du sie direkt auf deinem OpenSearch Server anpassen. Das geht aktuell nur über die internal_users.yml welche du unter /etc/opensearch/opensearch-security/internal_users.yml findest.
Die Passwörter sind idealerweise gehasht. OpenSearch stellt ein Tool zum Hashen von Passwörtern zur Verfügung. Das entsprechende Skript findest du hier:

/usr/share/opensearch/plugins/opensearch-security/tools/hash.sh

 

Willst du statt Passwörtern lieber Benutzer ändern, geht aktuell (soll aber deprecated werden) über das Securityadmin.sh Skript, indem du den korrekten Client-Key, das Client-Zertifikat, plus CA-Zertifikat gegen die OpenSearch-Instanz verifizierst.
Genau das tue ich, indem ich auf das Skript verweise. Dabei nutze ich das internal_users-File sowie Client-Key und Zertifikate, einschließlich der CA (Graylog-ca-Root). Zusätzlich gebe ich den FQDN meines OpenSearch an, gegen den ich das Skript ausführe.

bash /usr/share/opensearch/plugins/opensearch-security/tools/securityadmin.sh -f /etc/opensearch/opensearch-security/internal_users.yml -cert /etc/opensearch/opensearch.crt -key /etc/opensearch/opensearch.key -cacert /etc/opensearch/graylog-ca-root.crt -h opensearch.lan

Windows Command Line Logging

Ich finde, wir sind jetzt bereit, dafür weitere Felder der Indizes zu erkunden. Beispielsweise das Command-Line-Logging von Windows-Servern.

Nxlog zeigt in einem interessanten Audit, wie man unabhängig vom Active Directory schnell Command-Line Logging aktivieren kann. Ich habe das ganze ein bisschen erweitert und in ein Ansible Playbook gepackt.
Bitte beachte dabei, dass für diese Maßnahme aus datenschutzrechtlichen Gründen die Erlaubnis des betroffenen Clients erforderlich ist.

In diesem Prozess aktiviere ich die Auditpolicies für „Process Create“, „RPC Events“, „Process Terminate“ und „DPAPI“. Die Ergebnisse werden anschließend direkt im Winlogbeat erkennbar sein.

---
- hosts: windows
  tasks:
  - name: Configure Audit Policy for Process Creation
    win_shell: auditpol /set /subcategory:"Process Creation" /success:enable /failure:enable

  - name: Configure Audit Policy for RPC Events
    win_shell: auditpol /set /subcategory:"RPC Events" /success:enable /failure:enable

  - name: Configure Audit Policy for Process Termination
    win_shell: auditpol /set /subcategory:"Process Termination" /success:enable /failure:enable

  - name: Configure Audit Policy for DPAPI Activity
    win_shell: auditpol /set /subcategory:"DPAPI Activity" /success:enable /failure:enable

  - name: Configure Audit Policy for PNP Activity
    win_shell: auditpol /set /subcategory:"Plug and Play Events" /success:enable /failure:enable

  - name: Enable Command Line in Process Creation Event
    win_shell: Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" -Name ProcessCreationIncludeCmdLine_Enabled -Value 1

  - name: Reboot the system
    win_reboot:

Opensearch Discover

Zum Abschluss werfen wir noch einmal einen Blick in OpenSearch Discover. Im Bereich „Selected Fields“ siehst du nun die von mir ausgewählten Winlogbeat-Felder sowie einige erfasste Eingaben der „Windows Command Line“. Durch einen Klick auf das Plus-Symbol neben den „Available Fields“ werden diese zu „Selected Fields“ hinzugefügt. So einfach kann die getroffene Auswahl kenntlich gemacht werden.

Bist du nun ebenfalls bereit, deine Log-Management-Strategie zu optimieren und Security mehr in den Fokus zu rücken? Falls du Hilfe bei der Implementierung von OpenSearch, Elastic oder Graylog benötigst, stehen dir ich und meine Kolleg:innen von NETWAYS gerne zur Seite. Mit unserer Erfahrung sorgen wir für eine für dich maßgeschneiderte Log-Management Lösung. Wir freuen uns auf deine Nachricht.

OpenSearch – TLS für den Elastic-Fork

von | Sep 7, 2023 |

This entry is part 1 of 5 in the series OpenSearch Security

Wir erhalten vermehrt Kundenanfragen, die sich für den Teil A 8.15 Logging der ISO 27001 interessieren und beim Logging-Teil Unterstützung möchten. Je nach Bedürfnissen & Funktionsumfang hast du die Wahl, ob du Elasticsearch oder OpenSearch als Backend möchtest.
Wir bei NETWAYS verwenden beide Projekte, denn sie bieten unterschiedliche Möglichkeiten und vor allem verschiedene Security-Ansätze. Dadurch können wir unseren Kunden immer die bestmögliche Lösung für ihre Umgebung anbieten.

Bevor wir tiefer in die die Welt der OpenSearch Security einsteigen und uns der OpenSearch TLS Verschlüsselung widmen, gibt es für alle Interessierten einen kurzen Exkurs. Denn wer steckt eigentlich hinter OpenSearch und warum ist der Elastic Fork mittlerweile so relevant.

OpenSearch ist die AWS Antwort zu Elastic

In ihrem offiziellen FAQ beschreibt sich das OpenSearch Projekt selbst als „Open Source Search and Analytics Suite„, das von AWS unterstützt wird. Wir als Anwender:innen können dementsprechend eine langfristige Maintenance erwarten. AWS ist dabei nicht das einzige namhafte IT-Unternehmen, das seine Ressourcen für die Weiterentwicklung von OpenSearch bereitstellt. Unter anderem gehören RedHat, SAP und CapitolOne zu den weiteren Unterstützern des Projekts.
Auch Graylog empfiehlt seinen Anwender:innen in der Dokumentation für neue Installationen zukünftig auf OpenSearch zu setzen.

Sind Elastic und OpenSearch also das gleiche Tool, nur mit anderem Namen? Nein, auch wenn sie auf den ersten Blick ähnliche Aufgaben erfüllen: Einsammeln, Ablegen und Durchsuchen von Datensätzen.
Die Differenzen beginnen bei allen anderen Funktionen. Seien es Features zur Authentifizierung, die Speicherung der Daten oder die besonders relevante Frage „Was bedeuten meine Daten und wie kann ich diese schützen?“.

Wenn du abseits dieser grundlegenden Informationen mehr zu den Hintergründen der Entstehung von OpenSearch erfahren willst, lege ich dir den Blogpost meines Kollegen Daniel Neuberger ans Herz. Darin hat er sich ausführlich mit den Hintergründen des Forks sowie einer Gegenüberstellung der beiden Tools beschäftigt.

OpenSearch TLS Verschlüsselung

Anstatt auf die Installation von OpenSearch einzugehen (neben der offiziellen Doku gibt es z.B. von Graylog eine Installation in zehn Zeilen Code) beschäftige ich mich mit einem anderen wichtigen Thema: Sicherheit. Genauer gesagt mit der TLS Verschlüsselung von OpenSearch.

Warum genau dieses Thema?
Weil die Sicherheit in Softwarelösungen und besonders die Verschlüsselung der Kommunikation heutzutage wichtiger ist denn je. Und OpenSearch bietet seinen Anwender:innen vielfältige Konfigurationsmöglichkeiten.
Solltest du also mehrere Server in OpenSearch eingebunden haben, die auf mehrere Netze verteilt sind, willst du auf jeden Fall TLS aktiviert haben. Zudem machst du es einem potenziellen Angreifer, wenn er es schaffen sollte, so tief in deine Infrastruktur zu gelangen (und TCPDump aktivieren will, um Credentials und Secrets abzufangen) schwer.
Das Stichwort lautet hier für Angreifer: Impose Cost.

Bevor ich dir meine Vorgehensweise zur OpenSearch TLS Verschlüsselung zeige noch ein wichtiger Hinweis:

Es ist wichtig zu beachten, dass Downgrades / Upgrades von TLS oder das Löschen von Zertifikaten potenzielle Angriffsvektoren in deiner Log-Pipeline sein können. Daher kann die Überwachung von Zertifikaten, Hosts und Fehlerprotokollen mithilfe von Monitoringsystemen, etwa Icinga signifikant dazu beitragen, die Sicherheit und Verfügbarkeit deiner Systeme zu verbessern.
Aus sicherheitstechnischer Sicht ist es zudem äußerst lobenswert, dass die offizielle Dokumentation von OpenSearch zeigt, wie man Zertifikate ausstellt und die standardmäßig verwendeten Demo Zertifikate löscht.

Für die TLS Verschlüsselung meines OpenSerch teile ich dir Dir meine /etc/opensearch/opensearch.yml , die Kernkonfigurationsdatei des OpenSearch Projektes, die alles relevante enthält. Wichtige Eckpunkte dafür sind:

  • graylog-ca-root.crt dient als CA
  • opensearch.crt wird als Clientverwendet
  • TLS wird für den Transport & HTTP-Weg benötigt
  • Self-Signed Zertifikate werden als „Demo“ geführt
  • Ich aktiviere Audittypen, Snapshots und weise Features RestApi–Zugriff zu.

Weitere Parameter kannst du der offiziellen Doku entnehmen. Dennoch sollte meine Konfiguration, angepasst an deine self-signed Zertifikate, problemlos direkt funktionieren und zu einer erfolgreichen TLS Verschlüsselung führen.
(Zum eindeutigen Verständnis aller Prozesse innerhalb der Konfigurationsdatei habe ich relevante Bereiche mit Kommentaren versehen.)

# WARNING: revise all the lines below before you go into production

plugins.security.ssl.transport.enabled: true
plugins.security.ssl.transport.pemcert_filepath: /etc/opensearch/opensearch.crt
plugins.security.ssl.transport.pemkey_filepath: /etc/opensearch/opensearch.key
plugins.security.ssl.transport.pemtrustedcas_filepath: /etc/opensearch/graylog-ca-root.crt

# Ist die Zertifikatskette nicht korrekt auf die subjectAltName mit FQDNs / IPs gesetzt, teste mit "false" & korrigiere danach mit true
plugins.security.ssl.transport.enforce_hostname_verification: true

plugins.security.ssl.http.enabled: true
plugins.security.ssl.http.pemcert_filepath: /etc/opensearch/opensearch.crt
plugins.security.ssl.http.pemkey_filepath: /etc/opensearch/opensearch.key
plugins.security.ssl.http.pemtrustedcas_filepath: /etc/opensearch/graylog-ca-root.crt

plugins.security.allow_default_init_securityindex: true

# Self-Signed Zertifikate werden unter "unsafe_democertificates" geführt
plugins.security.allow_unsafe_democertificates: true

plugins.security.authcz.admin_dn:
  - "CN=opensearch.lan,OU=nps,O=nw,L=nbg,ST=by,C=de"
plugins.security.nodes_dn:
  - "CN=opensearch.lan,OU=nps,O=nw,L=nbg,ST=by,C=de"

plugins.security.audit.type: internal_opensearch

plugins.security.enable_snapshot_restore_privilege: true
plugins.security.check_snapshot_restore_write_privileges: true
plugins.security.cache.ttl_minutes: 60

plugins.security.restapi.roles_enabled: ["all_access", "security_rest_api_access"]
plugins.security.system_indices.enabled: true

#opendistro_security.audit.config.disabled_rest_categories: NONE
#opendistro_security.audit.config.disabled_transport_categories: NONE

#node.max_local_storage_nodes: 3
######## End OpenSearch Security Demo Configuration ########

action.auto_create_index: true

#Wichtig: Aktivierungs-Trigger der TLS-Konfiguration:
plugins.security.disabled: false

OpenSearch und besonders die Sicherheitsaspekte der Software werden mich auch in den kommenden Wochen noch weiter beschäftigen.
Wenn du zu diesem oder anderen Themen rund um OpenSearch oder Elastic Fragen hast, stehen ich oder meine Kolleg:innen dir gerne mit unserer Expertise zur Seite. Wir helfen dir dabei, Projekte zu planen, Umgebungen zu simulieren oder Entscheidungen basierend auf deinen verfügbaren Ressourcen zu treffen.

Obwohl du bei einem Termin meist einen Consultant als Ansprechpartner:in hast, bekommst du das kollektive Wissen unserer Abteilung. Gerne helfen wir dir, TLS in Verbindung mit Graylog oder anderen Produkten über deinen kompletten Stack über alle Clients und Server auszurollen.

Graylog Operations vs. Security. Und was ist mit Opensearch?

von | Nov 10, 2022 | , ,

Bereits im Juni hatte mein Kollege Christian Stein vom neuen Versions-Model bei Graylog berichtet. Graylog Enterprise ging in Graylog Operations und in Graylog Security auf.

Eine damit große verbundene Neuerung war die Unterstützung von Opensearch (ein Fork von Elasticsearch). Opensearch kann nun in allen Versionen Graylog Open Source, Graylog Operations und Graylog Security verwendet werden. Aber was bedeuten die einzelnen Versionen und warum der Opensearch Support.

Warum Opensearch?

Elastic hatte Anfang 2021 die OSS-Versionen des Stacks abgekündigt. Dies geschah als Reaktion auf die Auseinandersetzung mit AWS. Somit war elasticsearch-oss 7.10.2 die letzte reine Open Source Version von Elasticsearch. Für viele Service-Anbieter  wie z.B. AWS war das eine große Herausforderung, denn mit der neuen DUAL-License kann elasticsearch x-pack unter anderem nicht als kommerzieller Service bereitgestellt werden. Die Reaktion hierauf war der Fork Opensearch.

Graylog hat bis heute einzig elasticsearch-oss 7.10.2 (x-pack funktioniert auch) als unterstützte Version aufgeführt.

Gründe für Opensearch

  • Elasticsearch 7.10.2 ist schon lange abgekündigt, also EOL. Somit ergibt sich über die Zeit eine Liste von möglichen CVE
  • Opensearch ist unter einer Apache License v2 Open Source
  • Opensearch hat in den aktuellen Versionen 1.3.5 und 2.2 ein Machine-Learning Plugin, welches eine ML basierte Anomalie-Erkennung möglich macht.

Und genau letzteres ist vermutlich der mit größte Punkt, denn in Graylog Security gibt es eine auf diesem Plugin gestützte Anonmalie-Erkennung.

Wichtig zu wissen: Graylog unterstütz nur Opensearch Version 1.3.5

Empfehlung

Es ist nicht absehbar, dass die offizielle Unterstützung von Elasticsearch in neueren Version in naher Zukunft oder vielleicht überhaupt realisiert wird. Zumindest gibt es Stand heute keine Anzeichen dafür. Daher seid Ihr auf der sicheren Seite, wenn Ihr direkt mit Opensearch beginnt oder mittelfristig eine Migration von Elasticsearch zu Opensearch plant und durchführt. Eine Beschreibung für die Migration ist in der Graylog-Dokumentation hinterlegt. Hierbei ist einiges zu beachten. Also ist das Thema Opensearch auch unabhängig von der Verwendung einer Graylog Security Variante zu sehen.

Graylog Operations vs. Security

Schauen wir hier noch mal genauer in den Vergleich

Graylog Operations

Graylog Operations erweitert Graylog Open Source um folgende Punkte:

  • Audit-Log: Protokollierung von Adminstoren und Benutzer-Vorgängen in Graylog selbst
  • Log-View: Real-Time Ansicht der Logs
  • Archive-Funktion: Indices lassen sich zusätzlich vor dem löschen, sichern und später wieder herstellen.
  • Teams: Benutzer lassen sich in sogenannten Teams mit AD-Gruppen abbilden, welche in den Berechtigungen genutzt werden können
  • Event-Correlation: Definierte Events/Alerts lassen sich bei der Detektierung miteinander verknüpfen.. Dies ermöglicht eine genauere detektierung
  • Erstellung von Reports
  • Custom-Themes
  • Graylog-Forwarder
  • Illuminate: Eine Art Content und Processor Paket, welches eine Aufbereitung der Informationen nach dem GIM und SIEM mit sich bringt, Ebenfalls befinden sich für einige Produkte wie z.B. Windows oder Fortigate Implementierungen zur Datenaufbereitung in diesem Bundle. Das Umfasst dann auch neben der Aufbereitung Dashboards und Events.

Graylog Security

Graylog Security beinhaltet alles was Graylog Operations beinhaltet und die bereits erwähnte Anomalie-Erkennung.

Diese Anomalie-Erkennung bringt einige Dashboards und bereits vorgefertigte Machine-Learning Regeln mit, welche zu den Inhalten im Illuminate Bundle passen.

Hinweis: Zum jetzigen Zeitpunkt lassen sich keine eigenen Regeln für die Anomalie-Erkennung schreiben.

Zum Ende bleibt zu sagen…

Dieser Blog-Post war eine sehr theoretische Aufstellung der „großen“ Änderungen in Graylog in diesem Jahr. Bestimmt kommt auch noch das ein oder andere mal ein Blog-Post mit einem technischen Tiefgang wohl dann zum Einsatz von Opensearch mit Graylog bzw. eine Post zur Migration. Denn die Leichtigkeit bei der Installation und der Betreuung eines Opensearch-Clusters im Graylog-Kontext, ist noch ausbaufähig. Wer sein Opensearch-Cluster nicht im Griff hat, der kann in Graylog nicht gewinnen. Das ist ein Fakt.

Aber Ihr seid nicht alleine. Wenn Ihr Unterstützung bei der Umsetzung einer Graylog-Umgebung oder einer Migration von Elasticsearch auf Opensearch benötigt, meldet euch einfach bei den Kolleginnen und Kollegen von Sales. Das Team von Professionell Services hilft euch gerne bei euren vorhaben.

Daniel Neuberger
Daniel Neuberger
Senior Consultant
Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.
Lies mehr von Daniel und triff unser Team

NETWAYS Webinare – Die nächsten Themen

von | Okt 17, 2022 | , , ,

Wie viele vielleicht wissen führen wir auf unserem YouTube-Kanal eine Vielzahl von Webinaren durch. Diese handeln nicht nur von Icinga, sondern beispielsweise auch Elastic und Graylog. Im Laufe der Zeit sind wir von den einzelnen, getrennten Webinaren zu Serien gewechselt, in welchen wir nicht nur Icinga von Anfang bis Ende installiert und konfiguriert haben, sondern auch Elastic.

Graylog Webinar-Serie

Um diesen Kreis zu vervollständigen, planen wir aktuell eine Webinar-Serie zu Graylog. Hierzu haben wir bereits mit dem groben Überblick zu Graylog begonnen und werden in den nächsten Monaten diese Themen weiter ausbauen und ähnlich wie bei Elastic, eine Schritt für Schritt Reihe durchführen, um einzelne Themenbereiche zielgerichtet zu erläutern und zu erklären. Beinhaltet davon wird sein:

  • Installation und Konfiguration
  • Inputs und Pipelines
  • Graylog Marketplace
  • Dashboards und Visualisierung
  • Graylog Operations
  • Graylog Security

Natürlich sind wir für Vorschläge und Themeninhalte offen und können diese sowohl vorab als auch während der Webinare – sofern möglich – aufzeigen.

Elastic Webinare

Unsere Elastic Webinar-Reihe ist bereits mit einigen Themen versorgt worden. Dennoch gibt es hier noch einige Punkte, welche wir gezielt in weiteren Webinaren ansprechen wollen. Das beinhaltet unter anderem:

  • Elastic Enterprise
  • Pipelines
  • Elastic Security
  • Elastic Agent

Damit wären die ersten, wichtigsten Themen rund um Elastic abgeschlossen und können in künftigen Webinaren auf die Neuheiten in den jeweiligen Versionen eingehen.

Icinga Webinare

Mit den Webinaren zur Open Source Monitoring Lösung Icinga haben wir vor vielen Jahren angefangen und führen diese stetig weiter. Auch wenn wir bereits die größten Themenbereiche abgedeckt haben, ist unser Ziel weiterhin allgemeine Icinga Webinare durchzuführen, haben aber auch bereits einige weitere Themen in der Pipeline:

  • Icinga DB Installation
  • Migration von IDO zu Icinga DB
  • Icinga for Windows

Der wichtigste Bereich wird hier zunächst die Icinga DB sowie die Migration von der IDO sein. Darüber hinaus bietet Icinga for Windows noch eine Reihe an Möglichkeiten, das Windows Monitoring noch besser vorzustellen und einzelne Punkte detaillierter zu beleuchten.

Prometheus Webinare

Seit neuestem haben wir auch Prometheus als Produkt im Portfolio und möchten hier natürlich nicht die Gelegenheit auslassen, dieses Open Source Tool ebenfalls in verschiedenen Webinaren vorzustellen. Der erste Termin musste aus organisatorischen Gründen zwar abgesagt werden, sind aktuell aber bereits an der Terminfindung für neue Slots.

Wo finde ich die Termine

Wir werden auf unserem YouTube-Kanal Termine zu den Webinaren einplanen, sobald wir fixe Slots verfügbar haben. Hierfür am besten den Kanal abonnieren und die Glocke aktvieren, um über Neuheiten informiert zu werden. Alternativ kann man auch unseren Webinar-Kalender abonnieren und verpasst somit keine Termine mehr!

 

Wir freuen uns wie immer über einen regen Austausch und werden im Laufe der nächsten Wochen und in 2023 die Themen und Termine weiter ausbauen. Bei Feedback, Fragen oder Themenanregungen freuen wir uns natürlich über eine Kontaktaufnahme!

Christian Stein
Christian Stein
Manager Sales
Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".
Lies mehr von Christian und triff unser Team

Aus Graylog ENTERPRISE wird Graylog Operations

von | Jun 8, 2022 | ,

Wie im Blogpost von Graylog bekannt gegeben, wurde die Lösung Graylog ENTERPRISE umbenannt in Graylog Operations. Der neue Name spiegelt dabei das Ziel von Graylog wider, sich verstärkt in den operational Bereich einzugliedern und Herausforderungen, die sich aus diesem ergeben, anzugehen.

Graylog Operations ist eine mächtige und dabei einfach zu bedienende Lösung, um Loginformationen und Ereignisse zu sammeln, zu korrelieren, aufzubereiten und visuell darzustellen. Dadurch werden mögliche Schwachstellen, Bottlenecks und zu verbessernde IT-Prozesse aufgezeigt und erlaubt es den Nutzern, mit diesen Reports die interne Infrastruktur weiter zu optimieren.

Graylog Security

Neben dem neuen Namen Graylog Operations und der daraus resultierenden Mission, ist Graylog Security nun ebenfalls flächendeckend verfügbar. Das Ziel von Graylog Security ist es, die interne IT auf mögliche Bedrohungen hin zu analysieren, schadhaftes Verhalten aufzudecken und die Cyberabwehr zu stärken.

Dabei hilft die kosteneffiziente Lösung, alle Informationen nicht nur zu sammeln, sondern auch auszuwerten, grafisch darzustellen und mithilfe der Reporting Funktion automatisiert detaillierte Reports über den aktuellen Status der Umgebung zu erstellen. Der Vorteil von Graylog Security ist dabei, dass die Informationen einfach eingesammelt und dargestellt werden können, ohne auf komplexe SIEM Lösungen zurückgreifen zu müssen.

 

Wir haben euer Interesse geweckt? Dann nehmt doch einfach Kontakt mit uns auf. Wir stehen bei Rückfragen und Informationen rund um Graylog Operations und Graylog Security gerne zur Verfügung!

Christian Stein
Christian Stein
Manager Sales
Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".
Lies mehr von Christian und triff unser Team

Trainings

Web Services

Events