Autor-Archive: Timur Özcan

Wie Sie Einstellungsprobleme bei TCP-Verbindungen diagnostizieren können

Was kann bei einem TCP-Handshake schief gehen?

Hier ist der erster Artikel einer Serie, die alle Informationen enthält, die Sie zur Behebung von Leistungsproblemen von Anwendungen benötigen, welche auf dem TCP-Protokoll basieren.

Schauen wir uns an, wie TCP-Sessions aufgebaut werden … und was schief gehen kann!

Das TCP-Protokoll ist ein verbindungsorientiertes Protokoll, was bedeutet, dass eine Verbindung aufgebaut und aufrechterhalten wird, bis die Anwendungsprogramme an jedem Ende den Austausch von Nachrichten abgeschlossen haben. TCP arbeitet mit dem Internet Protocol (IP).

TCP bietet eine zuverlässige, geordnete und fehlerfreie Übertragung. Um dies zu tun, besitzt TCP einige Funktionen, wie zum Beispiel Handshake, Reset, Fin, Ack, Push-Pakete und andere Arten von Flags, um die Verbindung aufrechtzuerhalten und keine Informationen zu verlieren.

TCP wird mit vielen funktionellen Protokollen verwendet, wie beispielsweise HTTP. Daher ist es wichtig zu wissen, wie TCP-Probleme diagnostiziert werden können. In dieser Artikelserie werden wir diese TCP-Metainformationen erläutern und erklären, warum sie für eine Fehlerbehebung wichtig sind und wie sie mit PerformanceVision (PV) ganz leicht gemessen werden können.

Wie wird eine Session gestartet? TCP-Handshake und Verbindungszeit

Eine TCP-Verbindung, die auch als 3-Wege-Handshake bezeichnet wird, erfolgt über SYN, SYN + ACK und ACK-Pakete. Aus diesem Handshake können wir eine Leistungsmetrik mit dem Namen Connection Time (CT) ermitteln, die zusammenfasst, wie schnelle eine Session zwischen einem Client und einem Server über ein Netzwerk aufgebaut werden kann. Weitere Informationen finden Sie in diesem hervorragendem Artikel auf Wikipedia.

Abb.1 – Wie TCP Handshakes analysiert werden

Die drei Schritte eines TCP-Handshakes sind:

1. Das ‚SYN‘ ist das erste Paket, das von einem Client an einen Server gesendet wird, es verlangt buchstäblich von einem Server, eine Verbindung mit ihm aufzubauen.

2. Wenn es möglich ist, antwortet der Server mit einem "SYN + ACK", was bedeutet, "Ich haben Ihre ‚SYN‘ erhalten und ich bin damit EINVERSTANDEN"

3. Schließlich sendet der Client ein ‚ACK‘, um die Verbindung zu bestätigen.

Wie TCP-Verbindungsfehler diagnostiziert werden

1 – SYN ohne Verbindungen

Die erste Sache, die Sie mit PV leicht diagnostizieren können, lautet: "Können meine Clients eine Verbindung zu meinen Servern herstellen?" Gehen Sie im PV-Menü zu Applikation – → Clients, wählen die Registerkarte TCP und setzen den Filter mit dem Namen “Nur einseitigen Fluss". Dadurch sehen wir nur den Verkehr vom Client zum Server und keine Antwort vom Server.

Abb.2 – Nur auf einseitige Flows filtern

Dies bedeutet, dass Sie nur die Top-Client-IPs mit nur einem Fluss vom Client und ohne Antwort sehen möchten.

Für fortgeschrittene Benutzer von PerformanceVision

Wir haben den Filter so festgelegt, dass nur einseitige Flows zu sehen sind, wodurch größtenteils ‚SYN‘ Probleme angezeigt werden, aber Sie könnten auch andere Arten von Flows erhalten. Um lediglich die ‚SYN‘ ohne Verbindungen zu ermitteln, werden Sie einenbenutzerdefinierten Filter verwenden müssen:

syn.count > 0 and ct.count = 0

Abb.3 – PV hat einseitige Flows gefunden und diese sortiert

Wie Sie auf den obigen Ergebnissen sehen können, gibt es mehrere IPs, die eine Verbindung zu einem Server (SYN> 0) fordern, aber keine Verbindung zu ihnen herstellen können (Connections = 0).

Hier sind häufige Fehlerfälle:

  • Eine Firewall verweigert diese Verbindungen – Sie können dieselbe Anfrage auf Client Zones (im selben Menü) anwenden, um festzustellen, ob sich die IPs in derselben Zone befinden.
  • Der Server existiert nicht mehr oder ist nicht verfügbar – dies geschieht häufig, wenn eine Server-IP geändert wird, aber einige Clients auch weiterhin die alte IP anfragen.

2 – Schlechte Verbindungsraten

In einer perfekten Welt sollten Sie 1 ‚SYN‘ pro TCP-Verbindung erhalten. PV stellt eine Metrik zur Verfügung, um diese Verbindungseffizienz zu sehen, was durch eine ‚SYN‘ pro Verbindungsrate (dies entspricht der Anzahl der SYN-Pakete, die mit der Anzahl der TCP-Sitzungen verglichen werden, die eingerichtet wurden) dargestellt wird. Diese Metrik befindet sich in den "Details" Tabellen und kann über die Registerkarte "TCP" geöffnet werden. Sie können auch die zeitliche Entwicklung über Anwendung → benutzerdefinierte Diagramme grafisch darstellen.

Abb.4 – PV benutzerdefinierte SYN/Conn Tabellen

Eine schlechte „SYN“-Effizienz kann manchmal auch durch ein Netzwerkproblem ausgelöst werden. Somit wird die Fehlverbindung durch einen Paketverlust oder Kontingenz verursacht. Sie können diese Vermutung überprüfen, indem Sie die Verbindungszeit betrachten. Wenn diese niedrig bleibt und sich auf mehrere Hosts auswirkt, dann ist es wahrscheinlich ein Netzwerkproblem.

Wenn hingegen die Verbindungszeit hoch ist, aber das Problem beim Server liegt, ist dieser überlastet und kann nicht auf alle Clientanfragen antworten. Wenn schließlich die ‚SYN‘-Rate sehr groß ist, dann könnten Sie Sicherheitsprobleme haben, wie zum Beispiel einen DDOS-Angriff.

Fortgeschrittene Funktionen von PerformanceVision

Die Netzwerklatenz – RTT (Round Trip Time) – dies kann Ihnen einen weiteren Hinweis dafür geben, dass das Problem auf der Netzwerkseite liegt. PV stellt das RTT in der Metrik der Netzwerkleistung zur Verfügung.

Abb.5 – Eine Fehlerdiagnose von Verbindungen durch Verbindungszeiten und SYN-Raten

Fazit

In diesem ersten Artikel sahen wir eine kurze Darstellung der TCP-Leistungsmetriken und wie das TCP-Protokoll die Verbindungen mit SYN/SYN + ACK/ACK-Paketen verarbeitet. Wir sehen auch einige häufige Fehlerfälle, die leicht mit PerformanceVision diagnostiziert werden können.

Um diese Art von Problemen zu beheben, verwendeten wir die Page Top Clients, Top Client Zones und Custom Charts. Um einen Schritt weiter zu gehen, haben wir "Advanced Filter: Unilateral Flows" verwendet, um Flows ohne Antworten zu filtern.Wir haben zudem mehrere Metriken vorgestellt: die Anzahl der ‚SYN‘ und ‚Handshakes‘ (Verbindungen), die SYN-Effizienz und die Verbindungszeit. In nächsten Artikel werden wir einen Blick darauf werfen, wie Sie eine Verbindung mit Reset- und Fin-Paketen beenden können.

In der Zwischenzeit; falls Sie es ausprobieren möchten, können Sie einfach unsere Evaluation Virtual Appliance herunterladen:

Wie Sie Microbursts mit Savvius Omnipeek analysieren können

WIE-SIE-MICROBURSTS-MIT-SAVVIUS-OMNIPEEK-ANALYSIEREN-KOENNEN

Ein Microburst ist eine lokale und plötzlich auftretende Fallbö (Downdraft) innerhalb eines Gewitters, die in der Regel einen Durchmesser von 4 km besitzt, was meistens jedoch viel geringer ist. Mikrobrüche können zu erheblichen Schäden an der Oberfläche führen und in einigen Fällen sogar lebensbedrohlich sein.

In Computernetzwerken wird ein Microburst als kurzzeitiger Andrang von Daten definiert, der typischerweise nur Millisekunden dauert, was jedoch die Verbindung überlastet (Ethernet, Gigabit, 10 Gigabit usw.).

Ein Mikroburst ist ein ernsthaftes Bedenken für jedes Netzwerk, denn auch eine kurzfristige Überlastung des Netzwerks bedeutet, dass einige Benutzer keinen Zugriff auf das Netzwerk haben werden. Da der Industriestandard für die Messung der Netzwerknutzung in Bit pro Sekunde (bps) angezeigt wird, bleiben Mikrobursts oft unentdeckt, weil sie im Verlauf der Messung ausgeglichen werden.

In den meisten Fällen melden herkömmliche Netzwerküberwachungssysteme eine solche Überlastung nicht, weil diese nicht mehr als eine volle Sekunde vorhanden sind. Die Erfahrung des Endbenutzers kann deutlich eingeschränkt werden, wenn zu viel Netzwerkverkehr aufkommt oder Leistungsengpässe entstehen, die durch einen langsamen Datendurchlauf oder Verbindungsausfall verursacht wurden.

Um einen Microburst zu identifizieren, ist eine genaue Messung des Netzwerkverkehrs auf einem Link mit einer Mikrosekunden-Granularität sowie eine Visualisierung in Millisekunden erforderlich. Hier ist ein praktisches Beispiel für die Identifizierung eines Microbursts.

In diesem Beispiel befindet sich der Messpunkt auf einem TAP, der in einen 10-Gbit/s Link einer Rechenzentrumsverbindung eingefügt wird. Wir haben 45 Sekunden des Netzwerkverkehrs mit einem Savvius Omnipliance TL gemessen. Das Expertensystem von Omnipeek alarmiert sofort auf Unregelmäßigkeiten auf den OSI-Schichten 2 bis 7.

Diese Warnungen können auf der Basis einer der verfügbaren Spalten sortiert werden, z. B. durch Anzahl, Schichten usw. In diesem Fall sortieren wir nach Anzahl und sind dadurch in der Lage TCP-Wiederübertragungen, "Nicht reagierende" Peer Alerts, langsame Bestätigungen usw.

Abbildung 1: Omnipeek Expertensystem mit Strömungen, kategorisiert nach Protokollen/Anwendungen und Expertenereignissen, die nach Anzahl der Vorkommen sortiert wurden.
Abbildung 2: Ein Diagramm der Gesamtauslastung mit sekundengenauer Auflösung und den am meisten genutzten Anwendungen.

Wenn die Netzwerkauslastung unter Verwendung der typischen bps dargestellt wird, wie dies in Bild 2 der Fall ist, dann beträgt die maximale Vollduplex Spitze 2,54 Gbit/s, was bei einer Verbindung mit 10-Gbit/s und einer Vollduplexkapazität von 20 Gbps als nicht besorgniserregend gilt (senden und empfangen – 10 Gbit/s in jede Richtung).

Eine Sache, die wir in der Zusammenfassung des Compass Expert Events bemerkt haben, ist, dass es eine ziemlich große Anzahl von Ereignissen gibt, die mit langsamen Netzwerkproblemen in Verbindung stehen, insbesondere bei einer Messung von 45 Sekunden. Compass kann das Auftreten von Expert Events grafisch darstellen, wodurch deutlich wird, dass es eine Gemeinsamkeit in dem Neigungsverhältnis zwischen Expert Events und der gesamten Netzwerkauslastung gibt:

Abbildung 3: Die Compass-Funktion von Omnipeek kann das Vorkommen von Expert Events darstellen.

Da die Anzahl von langsamen Netzwerkereignissen recht umfangreich ist, lassen Sie uns zurück zum Nutzungsdiagramm gehen, um die Spitzen etwas näher zu untersuchen.

Wir können eine tiefer gehende Analyse durchführen, um dadurch eine Detailgenauigkeit in Millisekunden zu sehen, wobei wir mehrere Spitzen mit bis zu 9.845 Mbit pro Millisekunde feststellen konnten. Umgerechnet auf Sekunden (einfach multipliziert mit 1000), wäre dies 9.845 Gbps, und sollte dies in eine Richtung verlaufen, dann wird dies unseren 10 Gig Link vollständig auslasten.

Abbildung 4: Netzauslastung in Millisekunden-Granularität mit mehreren Spitzen von bis zu 10 Mbit pro Millisekunde

Interessanterweise wurde in Abbildung 4 das obere Protokoll in CIFS umgewandelt. Was ist also passiert?

Abbildung 5: Die übliche Ausnutzung durch TCP-Verkehr ist in Lila dargestellt, wohingegen die CIFS-Spitzen braun gekennzeichnet wurden.

Bei einer normalen Ausnutzung von bis zu 6 Mbit pro Millisekunde an TCP-Verkehr, können CIFS-Spitzen von bis zu 6 Mbit pro Millisekunde die Ausnutzung sogar auf 12 Mbit pro Millisekunde steigern, was die Kapazität eines 10 Gbit/s Links in eine Richtung gänzlich übersteigt.

In einer solchen Situation sind die Switches nicht mehr in der Lage den Datenverkehr zu puffern, bis die Bursts verschwunden sind, was dazu führt, dass Pakete verloren gehen und letztendlich TCP-Neuübertragungen verursacht werden, was die Expert Events eindeutig darlegen.

Savvius Omnipeek bietet eine sehr intuitive und kostengünstige Möglichkeit, um zu überprüfen, ob tatsächlich Mikrobursts in Ihrem Netzwerk auftreten, aber auch wann, wo und wie sehr die Netzwerkleistung darunter leidet.

Wenn Sie noch heute eine kostenlose und 30-tägige Testversion von Omnipeek ausprobieren möchten klciken Sie bitte hier: Omnipeek Trial Version

Virtualisierungen gehören zur Zukunft der Netzwerke

Im Moment gibt es wohl kein heißeres Modewort in der Technologiebranche als Virtualisierung – und das aus gutem Grund. Organisationen wenden sich in Scharen der Virtualisierung zu, um Kapazitäts- und Energiekosten, die mit dem Betrieb eines herkömmlichen Hardwarenetzwerks einhergehen, zu reduzieren.

Dennoch haben fast 60 Prozent der Unternehmen nach einem Bericht von Nemertes Research eine Verlangsamung in ihren Virtualisierungsbemühungen erkennen können. Auch wenn Organisationen und Unternehmen einige der Vorteile der virtualisierten Netzwerke nutzen, schöpfen viele von ihnen wahrscheinlich nicht das Optimum ab.

Netzwerkingenieure wissen nur allzu gut, dass eine virtuelle Topologie sich von Architekturen aus der Vergangenheit grundlegend unterscheiden. In einem virtuellen Netzwerk kommt der Datenverkehr niemals mit dem physischen Netzwerk in Berührung, wo er leichter zu erfassen und zu analysieren ist. Mit anderen Worten: Netzwerküberwachung ist in einer virtuellen Umgebung ein vollständig anderes „Tier“, das den Einsatz ganz anderer Werkzeuge und Hilfsmittel erfordert.

Eine gute Netzwerküberwachung für virtuelle Umgebungen muss kritische Anwendungen überwachen können, die in virtuellen Umgebungen laufen und sollte die Fähigkeit haben, das IT-Personal schnellstmöglich zu benachrichtigen, wenn Probleme auftreten. Savvius ‚OmniEngine arbeitet zum Beispiel als Anwendung auf einem virtuellen Netzwerk und kann den Datenverkehr, der zwischen einem physikalischen Host und virtuellen Maschinen fließt, analysieren. Auf diese Weise bleibt "unsichtbarer Datenverkehr" auch latent.

Da der Bandbreitenbedarf auch weiterhin steigt und Rechenzentren entsprechend dimensionieren, werden Virtualisierungen zunehmen. Neue Trends wie die Virtualisierung von Netzwerkfunktionen (NFV) und softwaredefiniertes Networking (SDN) gewinnen an Fahrt, wodurch die Überwachung unkonventioneller Netze noch dramatischer voranschreitet. Ein kürzlich veröffentlichter Bericht von Research & Markets zeigt auf, dass der NFV-, SDN- und Wireless-Networkinfrastrukturmarkt auf 21 Milliarden Dollar bis 2020 wachsen wird.

Die Wahrscheinlichkeit ist groß, dass Ihre EDV-Struktur entweder bereits mit einem virtuellen Netzwerk ausgeführt oder in naher Zukunft umgestaltet wird. Stellen Sie sicher, dass Sie das Optimum erhalten. Die OmniPeek Netzwerk-Analysesoftware ist Savvius preisgekrönte Lösung zur Überwachung, Analysierung und Fehlerbehebung von Netzwerken aller Art. Wie der Name schon sagt, wurde OmniPeek entwickelt, um umfassende Transparenz im Netzwerkverkehr zu gewährleisten: Lokal und remote, LAN und WLAN sowie für Netzwerke mit allen Geschwindigkeiten.

TCP Latency für Dummies

Der Einfluss von Paketverlust und Latenz auf den TCP-Durchsatz

Als Latenz (auch Latenzzeit) wird die Zeit bezeichnet, die benötigt wird, um ein Datenpaket über ein Netzwerk zu senden. Latenz kann auf unterschiedliche Weise gemessen werden: bidirektional (beide Richtungen), monodirektional (eine Richtung), usw.

Die Latenzzeit kann von jedem Teilstück der Kommunikationsverbindung, über welche das Datenpaket gesendet wird, beeinflusst werden: den Arbeitsplatz, die WAN-Verbindungen, Router, lokale Netzwerke (LAN), Server … und letztendlich kann diese – für große Netzwerke – durch die Lichtgeschwindigkeit begrenzt sein. 

Die Durchsatzrate ist definiert als gesendete/empfangene Datenmenge innerhalb einer definierten Zeiteinheit. Die UDP-Durchsatzrate wird von der Latenz nicht beeinflusst.  

UDP ist ein Protokoll, das verwendet wird, um Daten über ein IP-Netzwerk zu senden. Eines der Prinzipien von UDP ist, dass angenommen wird, dass die gesendeten Pakete vom Empfänger auch empfangen werden (oder eine entsprechende Steuerung findet auf einer anderen Schicht, beispielsweise einer Anwendung, statt).  

Theoretisch bzw. für bestimmte Protokolle (bei welchen auf keiner anderen Schicht eine Steuerung stattfindet – beispielsweise bei monodirektionalen Übertragungen) wird die Rate, zu der Datenpakete durch den Sender gesendet werden können, nicht von der Zeit, die zur Auslieferung an den Empfänger benötigt wird (=Latenz), beeinflusst.

Der Sender wird unabhängig von dieser eine definierte Anzahl an Datenpaketen pro Sekunde senden, die wiederum von anderen Faktoren abhängt (Anwendung, Betriebssystem, Ressourcen, …).

Warum wird TCP direkt von der Latenz beeinflusst?

  • TCP dagegen ist ein komplexeres Protokoll, da es einen Mechanismen integriert, der prüft, ob sämtliche Datenpakete auch korrekt geliefert werden. Dieser Mechanismus wird Bestätigung (engl. acknowledgement) genannt: Er veranlasst den Empfänger, an den Sender ein spezifisches Paket oder Flag (ACK-Paket bzw. ACK-Flag) zu senden, das den korrekten Empfang des Datenpakets bestätigt.
    Der Effizienz wegen werden nicht alle Datenpakete einzeln bestätigt: Der Sender wartet entsprechend nicht auf eine Bestätigung nach jedem einzelnen Paket, um die nächsten Datenpakete zu senden. Tatsächlich wird die Anzahl der Datenpakete, die gesendet werden können, bevor ein korrespondierendes Bestätigungspaket erhalten werden muss, von einem Wert, der als TCP Sendefenster (engl. TCP Congestion Window) bezeichnet wird, gesteuert.
TCP-Durchsatz vs Latenz
TCP-Durchsatz vs Latenz

Round trip latency TCP Throughput
0ms 93.5 Mbps
30ms 16.2 Mbps
60ms 8.07 Mbps
90ms 5.32 Mbps

Nehmen wir hypothetisch an, dass kein Paket verloren geht:

  • Der Sender wird ein erstes Kontingent an Datenpaketen gleichzeitig senden (entsprechend dem TCP Congestion Window). Erhält der Sender das Bestätigungspaket, wird das TCP Congestion Window vergrößert. Sukzessiv wird also die Anzahl an Paketen, die in einem bestimmten Zeitraum gleichzeitig gesendet werden können, steigen (Durchsatzrate). Die Verzögerung, mit welcher die Bestätigungspakete empfangen werden (=Latenz), hat einen Einfluss darauf, wie schnell das TCP Congestion Window vergrößert wird (entsprechend auch auf die Durchsatzrate). 
    Ist die Latenz hoch, bedeutet dies, dass der Sender länger untätig ist (keine neuen Pakete sendet), was wiederum die Geschwindigkeit, mit welcher die Durchsatzrate steigt, reduziert. 
    Die Testwerte (Quelle: http://smutz.us/techtips/NetworkLatency.html) sind sehr deutlich: Warum wird TCP durch wiederholte Paketsendungen (Retransmissions) und Datenverlust beeinflusst?

Der TCP Congestion Window Mechanismus geht folgendermaßen mit fehlenden Bestätigungspaketen um:

  • Bleibt das Bestätigungspaket nach einer fest definierten Zeit (Timer) aus, wird das Paket als verloren eingestuft und das TCP Congestion Window, also die Anzahl der gleichzeitig gesendeten Pakete, wird halbiert (die Durchsatzrate entsprechend auch – dies korrespondiert mit der Wahrnehmung einer restringierten Kapazität irgendwo auf dem Verbindungsweg seitens des Senders); die Größe des TCP Windows kann wieder ansteigen, wenn die Bestätigungspakete korrekt empfangen werden.

Datenverlust hat zwei Effekte auf die Geschwindigkeit der Datenübertragung:

  • Die Pakete müssen erneut gesendet werden (selbst wenn lediglich das Bestätigungspaket verloren gegangen ist, die Datenpakete aber empfangen wurden) und das TCP Congestion Window wird keine optimale Durchsatzrate zulassen: Dies gilt unabhängig vom Grund für den Verlust der Bestätigungspakete (Überlastung, Serverprobleme, Art der Paketschnürung, …) Ich hoffe, dies hilft Ihnen dabei, die Auswirkungen von Retransmissions/Datenverlusten auf die Effektivität Ihrer TCP-Anwendungen zu verstehen.

Der Einfluss von Paketverlust und Latenz auf den TCP-Durchsatz
Bei 2% Paketverlust ist der TCP-Durchsatz zwischen 6 und 25 niedriger als ohne Paketverlust.

Round trip latency TCP Throughput with no packet loss TCP Throughput with 2% packet loss
0 ms 93.5 Mbps 3.72 Mbps
30 ms 16.2 Mbps 1.63 Mbps
60 ms 8.7 Mbps 1.33 Mbps
90 ms 5.32 Mbps 0.85 Mbps

Datendiebstahl kann jeden treffen

Ein Verlust oder Diebstahl von Daten kann eine besorgniserregende Erfahrung für jedes Unternehmen sein. Wie dies auch schon große Einzelhändler, einschließlich Home Depot, Staples und Kmart, aber auch Banken und Gesundheitsorganisationen im letzten Jahr schon zu spüren bekommen haben, können Cyberangriffe jederzeit auftreten und von einer beliebigen Quelle stammen.

Leider können Sie in der modernen Welt nicht alles haben, denn es ist unmöglich Ihre Daten zu automatisieren und wettbewerbsfähig zu bleiben, wenn Sie sich von der digitalen Technologie abschotten. Die Datenerfassung ist einfach ein Bestandteil der heutigen Lebensweise, die wir alle akzeptieren müssen, aber dennoch müssen Unternehmen zunehmend eine hohe Sicherheit garantieren und die Privatsphäre von Einzelpersonen schützen.

Zum Glück kann ein Datendiebstahl manchmal vermieden oder auch einfach nur auf ein Minimum reduziert werden. Es folgt eine Liste derjenigen Dinge, welche Unternehmen tun können, um einen Datendiebstahl zu vermeiden:

  • Das Teilen von Daten mit Dritten begrenzen
  • Online Zahlungsseiten verschlüsseln
  • Verdächtige oder unbekannte E-Mails ignorieren
  • Beschränken Sie die Anzahl der Seiten, mit denen Sie Ihre Kreditkarteninformationen Teilen
  • Vermeiden Sie zu viele persönliche Informationen auf Social Media Seiten preiszugeben
  • Ändern Sie PINs und Passwörter häufig
  • Frieren Sie Konten ein, von welchen Sie annehmen, dass diese 
  • Überwachen Sie Konten auf fragwürdige Gebühren

Sobald Sie diese einfachen Richtlinien übernommen haben, ist es wichtig, dass Sie auch weiterhin wachsam gegenüber einem Datendiebstahl sind, um auch weiterhin, denn Hacker auf alle Arten von Methoden zurückgreifen, um in Datenbanken von Unternehmen einzudringen. Um Ihre Datenbanken so gut wie möglich schützen, sollten Sie die folgenden fünf Schritte anwenden, wenn ein Datendiebstahl vermutet wird:

  • Kommunikation ist ein wichtiger Faktor nach einem Datendiebstahl: Informieren Sie alle Mitarbeiter darüber, dass eine Datenverletzung aufgetreten ist, und Sie als Unternehmen die Verantwortung dafür übernehmen. Seien Sie ebenfalls auch offen und klar darüber, warum dieser Datendiebstahl geschehen konnte. Danach sollten Sie die betroffenen Nutzer darüber informieren, wie sie die Auswirkungen eines Datendiebstahls aufklären können. Schließlich sollten Sie mit Ihren Mitarbeitern auch eine ehrliche Diskussion über die Quelle des Problems führen, in dem Bemühen, das ähnliche Probleme in der Zukunft vermieden werden.
  • Ziehen Sie Ihre IT-Ingenieure zu rat: Die Spurensicherung ist von entscheidender Bedeutung, um den Netzwerkverkehr zu analysieren und herauszufinden, warum eine solche Datenverletzung aufgetreten ist. Deshalb sollten Sie proaktiv sein und den gesamten Datenverkehr Ihres Unternehmens, einschließlich aller Datenpakete, für eine spätere Analyse speichern. Der archivierte Verkehr kann dann durch Sicherheitsexperten geprüft werden, um Anomalien zu erkennen und festzustellen, wo und wann eine Datenverletzung entstanden ist.
  • Verwenden Sie ein proaktives Sicherheitssystem: Obwohl Firewalls bestimmte Arten von externen Angriffen verhindern können, werden diese nichts gegen Malware ausrichten, welche in das Netzwerk des Unternehmens eingedrungen ist. Eine vielschichtige Vorgehensweise, welche eine hierarchische Suche nach Datum, Ereignis, IP-Adresse und Schadensausmaß umfasst, ist die beste Lösung, um Sicherheitslösungen anzusprechen.
  • Überprüfen Sie die Daten, die gestohlen wurden, um das Ausmaß des Schadens zu bestimmen: Ändern Sie alle Passwörter und kontaktieren Sie Ihre Auskunfteien, um diese zu informieren, dass ein Datendiebstahl stattgefunden hat, sodass entsprechende Maßnahmen unternommen werden können. Wenden Sie sich ebenfalls unverzüglich an alle Finanzinstitute, wie Banken und Kreditkartenunternehmen, um unautorisierte Transaktionen zu verhindern.
  • Schließlich haben die meisten Länder Gesetze verabschiedet, welche sich mit Datenschutzverletzungen befassen, wobei diese zum Beispiel umfassen, dass eine Person, welche ein Opfer von Datendiebstahl geworden ist, unmittelbar darüber informiert werden muss. Stellen Sie sicher, dass Ihre Mitarbeiter ebenfalls eine Vertraulichkeits- und Geheimhaltungsvereinbarung unterzeichnet haben, um eine weitergehende Haftung zu vermeiden, falls ein Mitarbeiter für den Datendiebstahl verantwortlich sein sollte. Außerdem wird die einer Datenschutzerklärung der erste Schritt sein, um Daten in der Zukunft zu schützen.
  • Während ein Diebstahl von Unternehmensdaten sich in Anzahl und Schwere erhöht, ist ein Zugang zu den ursprünglichen Datenpaketen entscheidend, um schnell die Quelle und das Ausmaß der Sicherheitsvorfälle im Netzwerk zu erkennen. Mit seiner einzigartigen Fähigkeit, den kritischen Netzwerkverkehr von Hunderten von Warnungen pro Tag zu erfassen und zu speichern, ist Savvius Vigil 2.0 die einzige Lösung, um eine Spurensicherung von Netzwerken im Falle eines Datendiebstahls zu ermöglichen, welcher so weit in der Vergangenheit zurückliegt, dass der stattgefundene Netzwerkverkehr mit herkömmlichen Lösungen nicht mehr verfügbar ist.

Thank you for your upload

Zum Inhalt springen