Aruba AOS-CX: Patches für mehrere Schwachstellen veröffentlicht

Der Hersteller HPE hat für die Produkte der Aruba-Sparte Mitte dieser Woche mehrere Updates für kabelgebundene Switch-Produkte mit AOS-CX veröffentlicht. Diese schließen mehrere Sicherheitslücken. Wir haben Ihnen hier die Wichtigsten Informationen zusammengefasst.

Um welche Sicherheitslücken handelt es sich?

In den Patches werden insgesamt vier Schwachstellen betitelt.

  • SAD DNS Vulnerability (CVE-2020-25705)
  • Remote Code Execution Via External Storage (CVE-2021-29143)
  • PHY Firmware Local Bypass Security Restrictions (CVE-2021-29149)
  • Path-relative Stylesheet Import (PRSSI) (CVE-2021-29148)

Bei der Schwachstelle SAD handelt es sich um einen Bug, der sich auf die Art und Weise, wie Antworten von ICMP-Paketen im Linux-Kernel behandelt werden. Dieser kann ausgenutzt werden um ein sogenanntes DNS Cache-Poisoning durchzuführen. Dabei kann eine Domain (zb. www.google.de) auf eine andere IP-Adresse weitergeleitet werden und ermöglicht potentiellen Angreifern so, bekannte Domains auf selbst erstellte oder kompromittierte Sites weiterzuleiten.

Für die zweite und dritte Sicherheitslücke werden administrative Zugangsdaten benötigt, weshalb diese hier nicht weiter erläutert werden.

Die letzte PRSSI-Schwachstelle bezieht sich auf eine Schwachstelle in der Web-GUI der Geräte. Aufgrund der Konfiguration der webbasierten Verwaltungsoberfläche können relative URLs innerhalb von HTML-Seiten das falsche Ziel weitergeben. Dadurch wird möglicherweise die angezeigte Benutzeroberfläche (UI) verändert und man könnte auf bösartige Webseiten geleitet werden.

Sind die Geräte in meinem Unternehmen betroffen?

Die Switche aus der Aruba 8400/8360/8325/8320 und Aruba 6400/6300/6200F Serie mit den unten stehenden Firmware-Ständen sollten umgehend auf einen aktuellsten Stand gebracht werden.

Betroffene Firmware Versionen von AOS-CX:

  • 10.04.xxxx – Versionen vor 10.04.3070
  • 10.05.xxxx – Versionen vor 10.05.0070
  • 10.06.xxxx – Versionen vor 10.06.0110
  • 10.07.xxxx – Versionen vor 10.07.0001

Was kann ich tun wenn ich betroffen bin?

Schnellstmöglich sollte auf eine aktuelle Firmware Version aktualisiert werden. Die Versionen, welche entsprechende Fixes mit sich bringen sind:

  • 10.05.0070 und höher
  • 10.06.0110 und höher
  • 10.07.0001 und höher

Achtung!

Betroffene Aruba-Produkte mit einer 10.04.xxxx Firmware Version müssen auf 10.05.0070 aktualisiert werden, um alle Schwachstellen zu beheben.

Benötigen Sie Unterstützung bei der Prüfung oder Umsetzung der Firmware-Updates? Ist Ihre Umgebung nicht mehr leistungsstark genug oder sind einfach Ihre Anforderungen gewachsen? Sprechen Sie uns an, wir helfen Ihnen gerne.

Weitere Informationen zu den Sicherheitslücken finden Sie auf der Herstellerseite unter:

https://www.arubanetworks.com/support-services/security-bulletins/

VMware vSphere: Kritische Sicherheitslücke im vCenter

Kürzlich gab VMware bekannt, dass es eine Sicherheitslücke in den Plugins des vCenter Servers bekanntgeworden ist (CVE-2021-21985). Betroffen hiervon sind die folgenden vCenter Versionen:

  • VMware vSphere 6.5
  • VMware vSphere 6.7
  • VMware vSphere 7.0
  • VMware Cloud Foundation Versionen 3.x und 4.x

Ohne Gegenmaßnahmen ist es Angreifern möglich, über das vSAN Health Plugin (Siehe Link) des vSphere Clients (HTML5) Schadcode in das System zu übertragen und Root-Rechte zu erlangen. Diese Sicherheitslücke betrifft auch Kunden, die kein vSAN im Einsatz haben, denn das Plugin ist standardmäßig installiert und aktiviert. Um diese Sicherheitslücke zu schließen hat VMware für die betroffenen vCenter-Versionen jeweils ein Update für den vCenter-Server bereitgestellt. In diesem wird gleichzeitig auch eine weitere Sicherheitslücke (CVE-2021-21986) geschlossen. Diese wurde seitens VMware hingegen als moderat gefährlich bezeichnet und ist im verlinkten KB-Artikel ebenfalls aufgeführt.

Response-Matrix der betroffenen Versionen

ProduktVersionCVE IdentifierCVSSv3EinstufungBehoben ab VersionWorkaroundsDokumentation
vCenter Server 7.0CVE-2021-219859.8Kritisch 7.0 U2bKB83829FAQ
vCenter Server6.7CVE-2021-219859.8Kritisch 6.7 U3nKB83829FAQ
vCenter Server6.5CVE-2021-219859.8Kritisch 6.5 U3pKB83829FAQ
VMware vCenter Response-Matrix für CVE-2021-21985
ProduktVersionCVE-IdentifierCVSSv3EinstufungBehoben ab VersionWorkaroundsDokumentation
Cloud Foundation (vCenter Server) 4.xCVE-2021-219859.8Kritisch 4.2.1KB83829FAQ
Cloud Foundation (vCenter Server) 3.xCVE-2021-219859.8Kritisch 3.10.2.1KB83829FAQ
VMware vCenter Cloud Federation Response-Matrix für CVE-2021-21985

Möglicher Workaround (nur ohne aktives vSAN möglich)

Falls es nicht möglich sein sollte, das Update kurzfristig einzuspielen, gibt es einen Workaround, der in dem VMware KB-Artikel 83829 beschrieben wird. Dieser sieht vor in den betroffenen vCenter Versionen das schadhafte Plugin in den Dateien

/etc/vmware/vsphere-ui/compatibility-matrix.xml

bzw.

C:\ProgramData\VMware\vCenterServer\cfg\vsphere-ui\compatibility-matrix.xml

über einen Editor zu deaktivieren. Dies funktioniert allerdings nur, wenn Sie kein VMware vSAN im Einsatz haben.

Sollten Sie noch Fragen zum Schließen der Sicherheitslücke haben oder Unterstützung bei der der Umsetzung benötigen, sind wir gerne behilflich. Kontaktieren Sie gerne kurzfristig unseren Servicedesk oder Ihren Account Manager.

Weiterführende Informationen

https://www.vmware.com/security/advisories/VMSA-2021-0010.html
https://kb.vmware.com/s/article/83829
https://blogs.vmware.com/vsphere/2021/05/vmsa-2021-0010.html

WLAN-Sicherheitslücke Fragattack

Vor wenigen Tagen hat der IT-Sicherheitsexperte Mathy Vanhoef eine Vielzahl an Sicherheitslücken in den WLAN-Standards der IEEE aufgedeckt. Laut Vanhoef sind vermutlich nahezu alle WLAN-Geräte mindestens von einer dieser Sicherheitslücken betroffen. Er selbst hat die Schwachstellen an 75 unterschiedlichen Geräten getestet. Zusammengefasst werden sie unter dem Begriff Fragattack. Dieser hat seinen Ursprung in der Funktionsweise der Angriffe bzw. des hier missbräuchlich ausgenutzten Kommunikationsverfahrens im IEEE 802.11-Standard, dem Fragmentieren der Anfragen.

Funktionsweise und betroffene Geräte

Die Sicherheitslücken betreffen alle WLAN-Sicherheitsstandards einschließlich des relativ jungen WPA3-Standards. Ermöglicht werden diese Exploits durch die Funktionsweise von WPA:

  • Anfragen können in mehrere Datenpakete aufgeteilt (fragmentiert) und dann beim Empfänger wieder zusammengefügt werden. Dieses Protokoll-Design ermöglicht es Hackern, manipulierte Authentifizierungsanfragen an das Netzwerk zu stellen.
  • Dabei entspricht nur das erste Paket einer echten Anfrage, während die darauffolgenden Pakete manipulierte Daten enthalten. Bei dem Zusammenbau dieser Datenpakete erkennt das Netzwerk die Zugehörigkeit dieser Teilpakete. Dadurch kann ein Angreifer ohne Kenntnis des WLAN-Passwortes oder Entschlüsselung manipulierte Daten in das Netzwerk schleusen.
  • Diese manipulierte Daten können dann eingesetzt werden, um beispielsweise Ports für versteckte externe Verbindungen zu öffnen oder unverschlüsselten Datenverkehr abzufangen bzw. zu manipulieren.

Vanhoef hat vor der öffentlichen Enthüllung dieser Designschwäche mit Hardwareentwicklern neun Monate im Voraus zusammengearbeitet, um diese Exploits zu beheben. Die daraus resultierende Patches sollen die Sicherheitslücken beheben, einige sind bereits seit März veröffentlicht. Problematisch sind jedoch die Netzwerkteilnehmer, die keine bzw. nur sporadische Sicherheitsupdates bekommen, wie etwa IoT-Geräte (z.B. Smart-Home Geräte). Die Hersteller raten zu einer kurzfristigen Aktualisierung der Firmware aller Geräte. Zudem sollte möglichst unverschlüsselter Datenverkehr in WLAN-Netzen vermieden oder administrativ unterbunden werden, sofern möglich.

Pikant ist zudem, dass gleichermaßen PSK/SAE- wie auch Enterprise-Authentifizierung der Geräte von den Schwachstellen betroffen sind. Viele sonst bekanntgewordene Schwachstellen im WLAN-Umfeld betrafen meist die eher unsicheren PSK-/SAE-Authentfiizierung über einen gemeinsamen Netzwerkschlüssel aller mit dem WLAN verbundenen Geräte, wie man es von zuhause kennt. Im Fall dieser Schwachstelle schützt die Authentifizierung via IEEE 802.1x daher Geräte nicht erheblich besser, als in vielen anderen Fällen.

Weiterführende Informationen zur Funktionsweise finden sich auf der von Vanhoef veröffentlichen Website (https://www.fragattacks.com/) und vor allem in einer seiner Präsentationen (Siehe Link), wo die Schwachstellen genau aufgezeigt werden.

Wie kam es dazu?

Im IEEE-Standard 802.11 (Abschnitt 10.6) ist das Fragmentieren der Anfragen beschrieben. Es wird nicht vor der Manipulation gewarnt und eine Konformität erfordert keine Überprüfung der erneut zusammengesetzten Pakete nach der Übertragung von Fragmenten.

"If security encapsulation has been applied to the fragment, it shall be deencapsulated and decrypted before the fragment is used for defragmentation of the MSDU or MMPDU."

CVE-Codes & BSI-Mitteilungen zu FragAttacks

Das BSI hat eine Warnung zu der Schwachstelle veröffentlicht, die hier (Link zur BSI-Warnung) abgerufen werden kann.

Liste der CVE-Codes zu FragAttacks:

  • CVE-2020-24588: Aggregation attack (accepting non-SPP A-MSDU frames)
  • CVE-2020-24587: Mixed key attack (reassembling fragments encrypted under different keys)
  • CVE-2020-24586: Fragment cache attack (not clearing fragments from memory when (re)connecting to a network)
  • CVE-2020-26145: Accepting plaintext broadcast fragments as full frames (in an encrypted network)
  • CVE-2020-26144: Accepting plaintext A-MSDU frames that start with an RFC1042 header with EtherType EAPOL (in an encrypted network)
  • CVE-2020-26140: Accepting plaintext data frames in a protected network
  • CVE-2020-26143: Accepting fragmented plaintext data frames in a protected network
  • CVE-2020-26139: Forwarding EAPOL frames even though the sender is not yet authenticated (should only affect APs)
  • CVE-2020-26146: Reassembling encrypted fragments with non-consecutive packet numbers
  • CVE-2020-26147: Reassembling mixed encrypted/plaintext fragments
  • CVE-2020-26142: Processing fragmented frames as full frames
  • CVE-2020-26141: Not verifying the TKIP MIC of fragmented frames

Was kann ich tun, um meine Geräte zu schützen?

In erster Linie sollte man sich ein paar Grundsätze wieder bewusst machen und zur Gewohnheit machen:

  • Regelmäßige Software- und Firmwareupdates auf allen Geräten einspielen.
  • Wo möglich aus Gründen der Sicherheit und Stabilität das Patchkabel dem WLAN bei sicherheitskritischer Kommunikation vorziehen.
  • Möglichst auf verschlüsselte Kommunikation achten (https:// in der Browserzeile). Hilfreich ist hier auch das Browserplugin https-everywhere (siehe Link) , was jede Browserkommunikation zu verschlüsseltem https zwingt.

Sollten Sie Unterstützung bei der Aktualisierung Ihrer Geräte benötigen, oder eine Überprüfung auf die Schwachstelle wünschen, wenden SIe sich gerne vertrauensvoll an uns.

Nach Hafnium ist vor…??? – Zeit für mehr Sicherheit mit Azure Sentinel

Durch die fortschreitende Digitalisierung und die immer steigende Komplexität der Informationstechnologie müssen auch die Administratoren sich immer wieder neuen Herausforderungen stellen. Die Daten der Unternehmen müssen vor fortschrittlicheren Cyber-Bedrohungen oder Schwachstellen in der eingesetzten Software (z.B. Exchange-Server und der HAFNIUM-Exploit vor kurzer Zeit) weiter fachkundig geschützt werden. Bei Problemen oder Sicherheitsvorfällen müssen in großen Mengen Logdaten gesichert und gesichtet werden. Meist war an dieser Stelle aber schon alles zu spät, die Administratoren im reaktiven Arbeits-Modus. Die Auswertungen nehmen Wochen oder Monate in Anspruch. Daher ist es in der heutigen Zeit noch wichtiger geworden, die Sicherheit der IT-Infrastruktur proaktiv im Blick zu behalten. Aber wie?

Im diesem Blog-Beitrag wollen wir eine Möglichkeit vorstellen, mit der diese reaktive Arbeit auf relativ einfache Art und Weise weitestgehend automatisiert werden kann: Azure Sentinel – der Cloud-basierten SIEM (Security Information Event Management)- und SOAR (Security Orchestration Automated Response)-Lösung von Microsoft.

Azure Sentinel wird von Microsoft seit 2019 angeboten und als Dienst innerhalb der Azure-Plattform betrieben. Auf dieser Basis ist mit einem aktiven Azure-Konto die schnelle Installation und der einfache Betrieb der Lösung möglich. Weitere Investitionen in Hard- und/oder Software sind nicht nötig. Die Abrechnung der genutzten Ressourcen (z.B. Log-Speicherplatz etc.) erfolgt, wie in Azure gewohnt, entweder nutzungsbasiert oder auf Basis von zuvor festgelegten Kontingenten.

Für die grundsätzliche Funktion sammelt und aggregiert die SIEM-Komponente fortwährend Logdaten, die in der gesamten IT-Infrastruktur des Unternehmens generiert werden. Dabei spielt es keine Rolle, ob die Daten von Systemen und Anwendungen aus der Cloud (auch Clouds anderer Anbieter) oder der lokalen Infrastruktur erzeugt und Azure Sentinel zugeführt werden. Mit den dafür genutzten Monitoring-Agenten auf Linux- oder Windows-Servern können auf gleichem Wege die Logdaten von Netzwerk- und Sicherheitsgeräten wie Firewalls oder dem Endpoint-Schutz gesammelt werden. Innerhalb dieser Datenmenge werden über Analyse-Regeln sicherheitskritische Vorfälle und Ereignisse identifiziert, kategorisiert und analysiert. Für die Erkennung werden unter anderem auch die im Mitre ATT&CK-Framework (https://attack.mitre.org/matrices/enterprise/) aufgeführten Angriffs-Taktiken und -Techniken genutzt. Erkannte Bedrohungen, Anomalien oder Angriffe werden automatisch innerhalb von Azure Sentinel als Incidents angelegt und damit zum weiteren Handeln der IT-Administration übergeben. Diese Administratoren können nun über die erstellten Incidents auf umfangreiche Details der Vorfälle zurückgreifen. Hier werden die beteiligten Objekte im Einzelnen aufgeführt und zusätzlich in einer Übersichtgrafik dargestellt, so dass Zusammenhänge schnell erfasst werden können.

In der Praxis bietet Azure Sentinel dafür schon von Haus aus eine Vielzahl von vorkonfigurierten oder individuell anpassbaren Daten-Konnektoren, mit denen auf einfache Weise die nötigen Daten strukturiert gesammelt werden können. Viele Konnektoren haben dieselben Datenquellen, so dass z.B. im Bereich der Server nur ein zu installierender Monitoring-Agent auf Windows- oder Linux-Systemen unterschiedliche Daten sammelt – egal ob sie in der Cloud oder lokal betrieben werden.

Azure Sentinel bietet aber standardmäßig nicht nur die Daten-Konnektoren an, sondern auch weitere Bausteine:

  • Analyseregel-Vorlagen zum Auswerten der Logdaten mit intelligenten KI-Algorithmen und maschinellem Lernen
  • Arbeitsmappen zur Visualisierung der Logdaten
  • Thread-Hunting-Regeln zur aktiven Suche von Sicherheitsbedrohungen
  • Analyse des Benutzer- und Entity-Verhaltens für zuverlässige, handlungsrelevante Informationen zu den Vorfällen

Um dann aber auch automatisiert auf die durch SIEM erkannten Sicherheitsbedrohungen zu reagieren geht die SOAR-Komponente einen weiteren Schritt: Azure Sentinel bietet dafür die sogenannten Playbooks an. Durch die bereits integrierten Konnektoren zu unterschiedlichen externen Systemen könne über Trigger und Aktionen auch komplexere Szenarien abgebildet werden, wenn durch SIEM ein Vorfall gemeldet wird. Hier z.B. eine Reaktion auf einen eventuell kompromittierten Benutzer:

Dieser Beitrag kann nur einen groben Überblick über das breite Leistungsspektrum von Azure Sentinel liefern. Haben wir Ihr Interesse für diesen zusätzlichen, proaktiven Schutz Ihrer IT geweckt? Dann sprechen Sie uns gerne für weitere Informationen oder eine Live-Demo in Azure Sentinel an. Gehört Microsoft 365 / Microsoft Azure bereits zu Ihrer IT-Infrastruktur, dann bieten wir Ihnen gerne auch einen individuellen Proof-of-concept direkt in Ihrer IT-Umgebung an.

Zero Day Sicherheitslücke in Microsoft Exchange

Wie vor einigen Tagen bekannt wurde, hat eine Hacker-Gruppierung namens Hafnium mehrere Zero-Day-Sicherheitslücken in Microsoft Exchange ausgenutzt. Am vergangenen Freitag hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) die „IT-Bedrohungslage Rot“ ausgerufen und aufgefordert, die Lücke schnell zu schließen. Ab 26. Februar begannen die Angreifer zusätzlich offenbar damit, automatisiert Hintertüren in verwundbare Exchange Server von Microsoft einzubauen, tausende Server pro Stunde wurden so attackiert. Erst am 3. März wurde zur Schließung der Sicherheitslücke ein Update von Microsoft zur Verfügung gestellt.

Bei uns auch?

Wie sicher sind Sie, dass Sie aktuell nicht betroffen sind?  

Microsoft hat für Sofort-Checks auf dem Exchange Server Analyse-Werkzeuge bereitgestellt, die wir sehr gerne für Ihren Schutz einsetzen. Wir haben in den letzten Tagen bereits zahlreiche betroffene Systeme bereinigt, neu aufgesetzt und für die Zukunft durch das Einspielen der aktuellen Patches neu abgesichert.

Gerne sind wir schnell für Sie mit Sofortmaßnahmen aktiv.
Sprechen Sie uns jederzeit an.

Ein Facebook User kippt Privacy Shield – und jetzt?

Privacy Shield bezeichnet die (Selbst-)Verpflichtung zur Einhaltung von Datenschutzstandards in den USA, die dem europäischen Datenschutzrecht genügen (Stichwort DSGVO). Unter diesem Schutzschirm konnten europäische Unternehmen DSGVO-konform Daten an Auftragsverarbeiter mit Sitz in den USA weitergeben, die sich nach EU-US Privacy Shield zertifiziert hatten.

Schutzschild zerschlagen

Kürzlich ist diese Praxis vom EuGH für ungültig erklärt worden („Schrems II“-Urteil vom 16. Juli 2020). Max Schrems, österreichischer Jurist und Datenschutzaktivist hatte mit seiner Klage vor dem EuGH schon für das Kippen des Privacy Shield Vorgängers, dem Safe-Harbor-Abkommen, gesorgt. Hintergrund ist die Praxis von Facebook, auch die Daten europäischer Nutzer nicht an seinem Standort in Irland oder andernorts auf europäischem Boden zu verarbeiten, sondern allesamt auch ungefragt in die USA zu transferieren. Diese Praxis für seine personenbezogenen Daten nahm Schrems zum Anlass seiner Klage. Spätestens seit den Enthüllungen von Edward Snowden ist bekannt, dass US-Unternehmen sich nicht an die Zusicherungen von Privacy Shield halten oder halten können, wenn US-Geheimdienste (und ihre Partner) etwas wissen wollen. Es gibt sogar konkrete US-Gesetze, die eine Massenüberwachung vorschreiben (z.B. FISA 702 und EO 12.333). Dies steht in vollkommenem Gegensatz zur europäischen Datenschutzgrundverordnung DSGVO.

Was nun?

Wer IT-Dienste in seinem Unternehmen nutzt, hat mit hoher Wahrscheinlichkeit Berührungspunkte zu dieser Problemstellung. Es fängt schon bei der öffentlichen Website an: welche Dienste werden genutzt, welche Fonts, welche Cookies von welchen Anbietern übertragen Informationen der Besucher in die USA? Haben Sie sich mal die Liste von Diensten und Cookies angeschaut, die Sie beim Besuch einer Website akzeptieren sollen?

Ihre eigene oder auch andere Websites können Sie mit Blacklight scannen, um einen Eindruck zu bekommen. Als kommerzieller Dienst bietet Cookiebot noch Mehrwerte. Dieser Artikel von Cookiebot diente auch als eine der Quellen für diesen Beitrag.

Für den Geschäftsbetrieb noch kritischer sind aber SaaS Dienste wie Office 365, Salesforce und viele andere, die heute omnipräsent auch in europäischen Unternehmen sind. Was gilt es hier nun zu beachten?

SaaS weiter nutzen

Stellen Sie vor allem sicher, dass Sie die von den Anbietern fast immer bereitgestellten „Standardvertragsklauseln“ abgeschlossen haben. Damit gehen Kunden eine direkte Vertragsbeziehung mit dem Anbieter ein, in der der Anbieter den Datenschutz zusichert. Diese Praxis wurde vom EuGH ebenfalls geprüft und für weiterhin geeignet befunden, ein adäquates Datenschutzniveau zu gewährleisten. Wohlgemerkt: der Mechanismus ist in Ordnung – die Standardvertragsklauseln einiger Anbieter müssen und werden inhaltlich voraussichtlich kurzfristig nachgebessert werden.

Bei Office 365 sollten Sie in jedem Fall darauf achten, dass der Datenspeicherort für Ihre Organisation auf Europa oder sogar Deutschland festgelegt ist:

Risiken bewerten

Datenschutzbeauftragte neigen dazu, auf „Nummer sicher“ zu gehen und lieber von der Nutzung abzuraten. Diese Haltung sollte differenziert hinterfragt und diskutiert werden. Neben den nicht ganz klar greifbaren Risiken, Dienste weiter zu nutzen auch unter vorübergehend nicht vollkommen belastbaren Standardvertragsklauseln, sind die Risiken, sich ganz akut in Teilen handlungsunfähig zu machen, wahrscheinlich größer.

Haftung

Wir können keine rechtliche Beratung zu diesem Thema anbieten, sondern stellen diese Informationen als Hinweise und Tipps zur Verfügung. Eine juristisch fundiertere Analyse – und natürlich auch Angebote zur Beratung – finden Sie zum Beispiel bei der audatis in Herford und Potsdam.

“Windows 10 sicher im Unternehmen”: Material zum heise-Webinar

Am 29. April 2020 hat unser Consulting-Leiter Nils Kaczenski für den heise-Verlag ein sehr erfolgreiches Webinar gehalten: “Windows 10 sicher im Unternehmen” war der Titel, der über 120 Teilnehmer anzog. Das Feedback des Publikums war hervorragend, viele interessierte Fragen der Zuhörer konnten noch im Webinar beantwortet werden.

image

In dem Webinar hat Nils Kaczenski zahlreiche Themen und Techniken vorgestellt. Die Teilnehmer äußerten großes Interesse, sich näher damit zu beschäftigen. Sie finden daher hier eine umfangreiche Materialliste zu allen besprochenen Themen sowie einige weiterführende Links.

Download “Materialliste Windows 10 sicher im Unternehmen” mw-Materialliste-Windows-10-sicher-im-Unternehmen.pdf – 993-mal heruntergeladen – 135 kB

Gern beraten wir Sie zur Sicherheit in Windows-Umgebungen – nutzen Sie dafür unser Kontaktformular.

SecIT – aber online: “Windows 10 sicher im Unternehmen” als Webinar

Der heise-Verlag bietet seinem Publikum eine hochwertige Alternative zu der Fachmesse “SecIT 2020”, die Ende März hätte stattfinden sollen. In Kooperation mit den Referent*innen führt der Veranstalter die redaktionellen Seminare aus dem Messe-Programm jetzt online durch. In den nächsten Wochen werden alle Interessierten Gelegenheit haben, die Sessions als Webinare zu nutzen.

image

Auch das stark nachgefragte Seminar “Windows 10 sicher im Unternehmen” mit unserem Consulting-Leiter Nils Kaczenski findet auf diesem Wege statt. Am 29. April 2020 ab 10:00 Uhr stellen wir dort die modernen Sicherheitstechniken vor, die das aktuelle Client-Windows mitbringt. Aus der Seminarbeschreibung:

Windows 10 ist modern, leistungsfähig – und umstritten. Wie setzt man es im Unternehmens-Netzwerk sicher ein? Welche Security-Funktionen bringt es mit? Reichen die Bordmittel aus oder benötigt man auf jeden Fall noch Werkzeuge von Drittanbietern?

Das Webinar beleuchtet den aktuellen “State of Windows 10” mit besonderem Fokus auf mittelständischen Unternehmen. Neben wichtigen Sicherheitsfunktionen spielen auch der Datenschutz und Empfehlungen des BSI eine Rolle. Abschließend weiten wir den Blick auf das Netzwerk: Welche administrativen Konstrukte versprechen in Zeiten von Emotet und Advanced Persistent Threats ein angemessenes Schutzniveau?

Details und Anmeldung:

[Windows 10 sicher im Unternehmen]
https://www.heise-events.de/webinare/windows_10

secIT 2020: IT-Sicherheitskonferenz mit mw-Know-how

imageDie secIT findet im März 2020 zum dritten Mal statt. Dem hannoverschen heise-Verlag ist es damit gelungen, die IT-Sicherheitskonferenz in der Branche zu etablieren. In diesem Jahr wird unser Haus sein Expertenwissen zum redaktionellen Programm der Messe beitragen.

Am 25. und 26. März 2020 öffnet die secIT des renommierten heise-Verlags ihre Pforten in der Eilenriedehalle des Hannover Congress Centrum. Mehr als 50 Aussteller und ein hochkarätig besetztes Rahmenprogramm machen die Veranstaltung zu einem wertvollen Forum der IT-Branche. Vor den beiden Messetagen bieten die Veranstalter einen optionalen Workshop-Tag am 24. März 2020 an, zu dem man ganztägige kostenpflichtige Seminare besuchen kann.

Doch auch das “reguläre” Vortrags- und Workshop-Programm der secIT richtet sich an Besucher mit hohen Ansprüchen. Neben zahlreichen Ausstellervorträgen und einem Special-Event mit “Crypto-Guru” Bruce Schneier aus den USA haben die Redaktionen des heise-Verlags eine eigene Reihe von halbtägigen Seminaren zusammengestellt, die von bekannten Fachexperten der IT-Community präsentiert werden. Dabei greifen die secIT-Macher auch auf Know-how unseres Hauses zurück: am 26. März 2020, dem zweiten Messetag, wird unser Consulting-Leiter Nils Kaczenski beleuchten, welche Security-Funktionen den Einsatz von Windows 10 im Unternehmen absichern. Interessenten sollten sich beeilen, denn der erste von zwei Terminen ist bereits ausverkauft.

Details zur secIT, das Programm und die Tickets finden Sie hier:

[secIT by Heise, die IT-Security Messe in Hannover]
https://sec-it.heise.de/

Apple prescht vor: Webserver-Zertifikate sollen schon nach einem Jahr ablaufen

Besonders die Betreiber kommerzieller Webseiten werden sich zügig umstellen müssen: Apple hat vor zwei Tagen (am 19. Februar 2020) eine Initiative angekündigt, die sie zwingt, ihre TLS-Verschlüsselungszertifikate künftig jährlich auszutauschen – statt wie bisher alle zwei Jahre. Das berichtet der Zertifikatsanbieter Digicert unter Berufung auf das „CA/Browser Forum“, das in dieser Woche in Bratislava getagt hat.

imageDer Digicert-Artikel dazu:

[DigiCert‘s Position on 1-Year TLS SSL Certificates]
https://www.digicert.com/position-on-1-year-certificates/

TLS-Zertifikate sorgen dafür, dass Webseiten verschlüsselt übertragen werden, sie sind auch unter dem veralteten Namen „SSL-Zertifikate“ bekannt. War es früher so, dass ein Unternehmen solch ein Zertifikat praktisch beliebig lang gültig lassen konnte, hatten sich die Browser-Hersteller in den letzten Jahren zunächst auf eine maximal dreijährige Laufzeit und zuletzt eine Begrenzung auf zwei Jahre geeinigt. Alle üblichen Browser akzeptieren TLS-Zertifikate seither nur, wenn deren Laufzeit zwischen Ausstellung und Ablauf höchstens zwei Jahre beträgt. Für den Betreiber einer Webseite bedeutet dies, dass er im selben Turnus die Zertifikate erneuern und austauschen muss. Das kann bei großen Webseiten durchaus einigen Aufwand bedeuten.

Alle Experten der IT-Industrie sind sich einig, dass kürzere Laufzeiten mehr Sicherheit bedeuten: Je länger ein Zertifikat im Einsatz ist, desto größer ist die Aussicht für einen Angreifer, dieses auf verschiedenen Wegen kompromittieren zu können. Dabei geht es weniger darum, die Verschlüsselung selbst zu knacken, das ist weitgehend aussichtslos. Eine lange Nutzungsdauer macht aber Patzer des Betreibers im Umgang mit den Zertifikaten wahrscheinlicher. So haben Hacker mehr Möglichkeiten, die zugehörigen privaten Schlüssel zu kapern und so Webseiten unter ihre Kontrolle zu bringen. Das ist nicht unwahrscheinlich: Hersteller Citrix etwa hatte vor wenigen Wochen in seinem Sicherheitsprodukt Netscaler eine Lücke, die den Zugriff auf diese privaten Schlüssel erlaubte.

Wie Digicert berichtet, hatte Google schon vor einiger Zeit gefordert, die maximale Laufzeit von TLS-Zertifikaten auf ein Jahr zu begrenzen. Die meisten anderen Browser-Hersteller lehnten ab, es blieb bei zwei Jahren. Vorgestern nun preschte Apple vor: Ab dem 1. September 2020 soll Apples Browser Zertifikate nur noch dann akzeptieren, wenn diese höchstens ein Jahr gültig sind. Webseiten, die das nicht erfüllen, wird Safari dann nicht mehr anzeigen. Zwar hat Safari auf PCs nur eine geringe Verbreitung, auf iPhones ist er aber der dominierende Browser. Die Änderung wird also große Auswirkungen haben – auch auf kleinere Firmen, deren Mitarbeiter über das iPhone etwa auf den Firmen-Mailserver zugreifen.

Aus diesem Grund ist davon auszugehen, dass für Firmen sehr bald kein Weg daran vorbeigeht, ihr Zertifikats-Management umzustellen. Der bisher meist manuelle Vorgang, ein TLS-Zertifikat auszutauschen, muss in vielen Fällen wohl automatisiert werden. Die Technik dafür existiert im Prinzip: Der Zertifikatsanbieter „Let’s Encrypt“ stellt seine kostenlosen TLS-Zertifikate nur für jeweils 90 Tage aus und setzt auf vollständige Automatisierung. Große Webseiten nutzen üblicherweise aber Zertifikate anderer Anbieter, weil diese erweiterte Eigenschaften bieten, die für Kunden ein höheres Vertrauensniveau erzeugen.