IT-Sicherheitsgesetz 2.0 verabschiedet

Nach langen Verhandlungen hat der Bundestag am 23.4.2021 „nach halbstündiger Aussprache“ – sprich, kurz und (je nach Standpunkt) schmerzlos bzw. -voll die Neuausgabe des IT-Sicherheitsgesetzes von 2015 beschlossen. Seit 2019 hatte es für die Novelle des Gesetzes, welches bis zuletzt nicht evaluiert worden war, eine Reihe von öffentlichen, nichtöffentlichen, geleakten und teilweise schnell wieder veralteten Entwürfen gegeben, die der kommentierenden Zivilgesellschaft einiges an Agilität abverlangten.

Am Ende konnte die viele – nicht wenige sagen: vernichtende – Kritik am Gesamtwerk nur wenig Änderungen bewirken; auch die Anträge der verschiedenen Oppositionsparteien wurden sämtlich abgeschmettert. Nun ist es, was es ist – und wird, wie bereits das ursprüngliche IT-SiG – konkret vor allem mit den folgenden Rechtsverordnungen ausgestaltet werden.

Klar ist aber schon, dass die Kompetenz des BSI stark erweitert wird. Es kann künftig Sicherheitslücken in IT-Systemen über öffentliche Telekommunikationsnetze mithilfe von Portscans suchen und semi-offensive Methoden wie Honeypots und Sinkholes einsetzen. Dazu mischt das BSI jetzt im Verbraucherschutz mit, etwa mit einem IT-Sicherheitskennzeichen.

Kritis-Betreiber sowie Betreiber im Energie-Sektor müssen bald Systeme zur Angriffserkennung („SOC“/„SIEM“) einsetzen. Außerdem müssen Erklärungen von Herstellern kritischer Komponenten eingeholt werden, dass keine Sabotage oder Spionage zu erwarten ist.

Bestimmte bislang schon geltende Pflichten für Kritis-Betreiber (v. a. die Meldepflicht) betreffen demnächst auch „Unternehmen in besonderem öffentlichen Interesse“ („UNBÖFI“), etwa in der Rüstungsindustrie und im Bereich Verschlusssachen („KRITIS-light“). Ebenso auf dem Radar sind nun Unternehmen, die der Störfallverordnung unterliegen, und Konzerne „von erheblicher volkswirtschaftlicher Bedeutung“ im Inland oder als Zulieferer mit „Alleinstellungsmerkmalen“. Neu betroffen ist der Sektor Entsorgung.

https://www.bmi.bund.de/SharedDocs/pressemitteilungen/DE/2020/12/it-sig-2-kabinett.html

Blitze-Wolke

HAFNIUM-Schwachstellen: Office 365/Microsoft 365/AD FS indirekt auch bedroht

[GTranslate]

Von Inés Atug, Markus Drenger und Daniel Jedecke.

Nach der Veröffentlichung des Out-of-Band-Patches für die als HAFNIUM bekannt gewordenen Schwachstellen in Exchange Servern haben viele Admins, die zuvor eine Migration nach Office 365 (jetzt Microsoft 365) durchgeführt hatten, aufgeatmet. Denn Microsoft zufolge ist Exchange Online von Hafnium nicht betroffen. Hiermit meint der Hersteller jedoch das Produkt an sich: Exchange Online ist weiterhin nicht direkt angreifbar. Aber Vorsicht: Es kann je nach Aufbau dennoch möglich sein, dass Angreifer auf den Cloud-Dienst durchgreifen können. 

In vielen Fällen ist in Unternehmen ein hybrider Aufbau etabliert, bei dem ein Exchange-Server weiterhin lokal betrieben wird. Sollte dieser Exchange-Server die HAFNIUM-Schwachstellen aufweisen, könnten Angreifer hierüber Zugriff auf das lokale Netzwerk erhalten (siehe Abbildung Schritt (1)) und sich dann über Lateral Movement im Netz weiterbewegen (Schritt (2)). Mittelbares Ziel des Angriffs ist in der Regel der Zugriff auf ein hochwertiges System wie beispielsweise das Active Directory oder die Active Directory Federation Services (AD FS) zu. Bei Zugriff auf letzteren können die Angreifer unter Umständen den geheimen Schlüssel entwenden (Schritt (3)), sich damit als jeder beliebige legitime Nutzer in der Cloud ausgeben (Schritt (4)) und somit Zugriff (lesen, verändern, löschen) auf alle in der Cloud gespeicherten Daten bekommen (Schritt (5)).

Angriff auf die Cloud/ADFS via HAFNIUM/ProxyLogon

Ob und wie leicht dies möglich ist, hängt stark davon ab, wie der lokale Aufbau umgesetzt ist. Wir erleben im Bereich der Forensik und Beratung hier gute wie auch ungünstige Umsetzungen. Prinzipiell sollte das Ziel immer sein, Lateral Movement in der On-Premise-Umgebung wie auch in der Cloud zu minimieren. Hierfür gibt es bewährte Verfahren, welche sich bei geeigneter Konfiguration dazu eignen, die Bewegungen der Angreifer im Netz zu erschweren:

  • Frühzeitiges Patchen von Sicherheitslücken: Die wichtigste Maßnahme, die auch bei Hafnium eine Kompromittierung mit hoher Wahrscheinlichkeit unterbunden hätte, ist das schnelle Patchen der Systeme. Hier herrscht bisweilen noch der Irrglaube, dass kritische Sicherheitslücken innerhalb von 30 Tagen zu patchen seien. Dies wurde und wird teilweise sogar noch von IT-Sicherheitsstandards vorgeschlagen. Sicherheitslücken, die mittels Fernzugriff automatisiert und unauthentifiziert ausgenutzt werden können, so wie dies bei Hafnium der Fall ist, zeigen jedoch deutlich, dass hier möglichst innerhalb von Stunden anstatt Tagen gepatcht werden sollte.
  • Administrative Trennung von Active Directory und Exchange Server: Eine weitere Maßnahme, die lokal umgesetzt werden sollte, ist die administrative Trennung zwischen Active Directory und Exchange. Oft sind die Systeme über Jahre gewachsen und eng miteinander verbunden. So trennt die Angreifer nach erfolgreicher Kompromittierung oft nur ein Powershell Kommando von der AD-Übernahme. Hier ist es wichtig, die 2017 von Microsoft im Rahmen der Konferenzen Blue Hat und Black Hat vorgestellten Probleme zu mitigieren. Hierfür eignet sich Split-Permissions (https://docs.microsoft.com/en-us/exchange/understanding-split-permissions-exchange-2013-help und https://docs.microsoft.com/de-de/exchange/permissions/split-permissions/configure-exchange-for-split-permissions?view=exchserver-2019). Eine weitere Maßnahme ist die Verwendung der Local Administrator Password Solution (LAPS) von Microsoft. Hierbei wird auf jedem Host ein separates Admin-Passwort gesetzt, um so das Springen nach einem erfolgreichen Angriff (beispielsweise mittels Pass-the-Hash-Angriffsarten) zu erschweren.
  • Umsetzen des Konzepts administrativer Zonen: Da AD FS das Sprungbrett in die Cloud Welt ist, sollte dieser Zugang besonders gesichert werden. Hierzu empfiehlt Microsoft seit längeren einen Aufbau, in dem verschiedene administrative Sicherheitszonen (engl. tiers) voneinander getrennt werden sollten. Ein entsprechend gesicherter Exchange Server würde hier in Zone 1 stehen und ein Active Directory in Zone 0. Ein Sprung zwischen diesen Zonen soll mit den umzusetzenden Maßnahmen stark erschwert werden. Für den AD FS empfiehlt Microsoft ebenfalls den Aufbau in der Zone 0 (https://docs.microsoft.com/de-de/windows-server/identity/ad-fs/design/best-practices-for-secure-planning-and-deployment-of-ad-fs).
  • Multifaktorauthentifizierung: Sowohl in der Cloud als auch in der lokalen IT-Umgebung sollten administrative Zugriffe mittels starker Multifaktorauthentifizierung abgesichert werden.
  • Protokollierung und Monitoring: Damit ein unberechtigter Zugriff möglichst schnell bemerkt wird, sollte ein feinmaschiges Monitoring- und Protokollierungskonzept etabliert sein. Insbesondere in der Cloud-Umgebung gehört das Monitoring neben der Zugriffssteuerung zu den wichtigsten Sicherheitsmaßnahmen. 
  • Datenklassifizierung: Sollte es doch zu einem Einbruch gekommen sein und die Angreifer möchten Daten exportieren, dann sollte mittels der Datenklassifizierung Sicherheitsmaßnahmen greifen, die zumindest die als vertraulich oder streng vertraulich klassifizierten Daten außerhalb der Cloud und des Kundennetzwerks unlesbar darstellen. 
  • Datensicherung: Sollte es zu einem Einbruch gekommen sein und es werden die Daten mittels Ransomware verschlüsselt, dann sollte man auf eine unveränderbare extern gespeicherte Datensicherung zurückgreifen können.

Die obigen Ausführungen zeigen, dass ein ganzheitliches und aktuelles Sicherheitskonzept notwendig ist, um möglichen Sicherheitslücken umfassend entgegenzuwirken. Überprüfen Sie daher regelmäßig Ihre Sicherheitsmaßnahmen und passen Sie diese ggfs. an geänderte Anforderungen an. Insbesondere, wenn Sie lokale Dienste von außen erreichbar konfigurieren oder Cloud-Dienste mit der lokalen IT-Umgebung koppeln, sollten das Sicherheitskonzept überprüft und nachgeschärft werden. Sprechen Sie uns gerne dazu an!  

HAFNIUM Exchange-Schwachstellen: Überblick

Die hochkritischen HAFNIUM-Lücken (CVE-2021-26855 aka ProxyLogon), CVE-2021-26857, CVE-2021-26858 und CVE-2021-27065) bedrohen weiterhin IT-Infrastrukturen weltweit. Auf dieser Seite haben wir die wichtigsten Informationen und Hilfsmittel für Sie zusammengestellt.

Update 14.4.2021: Durch neue kritische Exchange-Schwachstellen könnte eine weitere Hafnium-ähnliche Welle drohen.

Wie Sie den Medien entnehmen konnten oder in nicht wenigen Fällen auch in der eigenen Betroffenheit bemerkt haben, beherrscht das Thema der kritischen Microsoft Exchange Lücke zur Zeit die IT. Bei HiSolutions haben wir aus allen Bereichen Ressourcen zusammengezogen, um den sprunghaft gestiegenen Bedarf an Incident Response und Forensik auffangen zu können. Wir bitten um Verständnis, wenn der Zeitplan des einen oder anderen Projektes aktuell darunter leidet und danken vor allem für das große Verständnis – und dafür, dass wir alle gemeinsam an der Bewältigung dieser Krise arbeiten!

In den letzten Wochen konnten wir daher viele Anfragen zur Security nicht sofort annehmen. Sobald sich die aktuelle Lage beruhigt, würden wir uns gerne bei Ihnen zurückmelden, um Verbesserungen anzugehen.

ProxyLogon-Logo

Letzte Beiträge

  • Hafnium – Überwachen Ihrer Systeme mit Loki
    Auch mehr als ein Jahr nach der gravierenden Hafnium-Schwachstelle sind immer noch nicht alle Systeme abgesichert. Wir haben nun unsere Handreichung Hafnium – Überwachen Sie Ihre Systeme aktualisiert, um aufgrund der Lizenzbedingungen den Scanner Loki (statt Loki und Thor) zu empfehlen.
  • Hafnium Reloaded – Wieder kritische Schwachstellen in Microsoft Exchange
    Und täglich grüßt das Murmeltier? Nicht ganz. Trotzdem erleben wir aktuell ein Déjà-vu mit Microsoft Exchange: Am 13.04.2021 19 Uhr MESZ wurden vier neue hochkritische Schwachstellen samt dazugehörigem Patch veröffentlicht. Das BSI warnt bereits vor der Schwachstelle und fordert dazu auf, sehr zeitnah die eigenen Systeme zu patchen. Die Cybersecurity and Infrastructure Security Agency (CISA) des US Department of Homeland Security (DHS) geht sogar noch einen Schritt weiter und wird am Freitag, den 16.04.2021 alle nicht gepatchten Systeme aus dem […]
  • HAFNIUM/ProxyLogon: Self-Help Guide To Securing Microsoft Exchange
    Due to the high demand for current, in-depth information on how to mitigate the HAFNIUM/ProxyLogon vulnerabilities in Microsoft Exchange we translated our free German HiSolutions Self-Help Guide into English.
  • HAFNIUM-Schwachstellen: Office 365/Microsoft 365/AD FS indirekt auch bedroht
    [GTranslate] Von Inés Atug, Markus Drenger und Daniel Jedecke. Nach der Veröffentlichung des Out-of-Band-Patches für die als HAFNIUM bekannt gewordenen Schwachstellen in Exchange Servern haben viele Admins, die zuvor eine Migration nach Office 365 (jetzt Microsoft 365) durchgeführt hatten, aufgeatmet. Denn Microsoft zufolge ist Exchange Online von Hafnium nicht betroffen. Hiermit meint der Hersteller jedoch das Produkt an sich: Exchange Online ist weiterhin nicht direkt angreifbar. Aber Vorsicht: Es kann je nach Aufbau dennoch möglich sein, dass Angreifer auf den […]
  • HAFNIUM Exchange-Schwachstellen: Überblick
    Die hochkritischen HAFNIUM-Lücken (CVE-2021-26855 aka ProxyLogon), CVE-2021-26857, CVE-2021-26858 und CVE-2021-27065) bedrohen weiterhin IT-Infrastrukturen weltweit. Auf dieser Seite haben wir die wichtigsten Informationen und Hilfsmittel für Sie zusammengestellt. Update 14.4.2021: Durch neue kritische Exchange-Schwachstellen könnte eine weitere Hafnium-ähnliche Welle drohen. Wie Sie den Medien entnehmen konnten oder in nicht wenigen Fällen auch in der eigenen Betroffenheit bemerkt haben, beherrscht das Thema der kritischen Microsoft Exchange Lücke zur Zeit die IT. Bei HiSolutions haben wir aus allen Bereichen Ressourcen zusammengezogen, um den […]

HiSolutions Discovers New HAFNIUM/ProxyLogon IoCs

by Daniel Jedecke, David Fuhr und Vincent Rockenfeld

During our work on a large number of forensic analyses of HAFNIUM/ProxyLogon cases, we witnessed several cases where the recommended Microsoft tools (TestProxyLogon script and Safety Scanner/MSERT) do not find anything due to missing traces in the HttpProxy log. In those cases evidence can be found in the ECP Activity log as follow:

Indicators of Compromise (IoCs):

./ECP/Activity/ECPActivity_39844_20210303-1.LOG: 2021-03-03T06:43:32.531Z ,EX01, ,S:FE=EX01.FOOBAR.LOCAL;S:URL=https://ex01.foobar.local:444 /ecp/proxyLogon.ecp (https://owa.foobar.com/ecp/y.js);S:Bld=15.1.2106.2;S:ActID=def0-b0e6-2342-5e2c-23a8ff1962a1;Dbl:WLM.TS=0

./ECP/Activity/ECPActivity_39844_20210303-1.LOG: 2021-03-03T06:43:32.963Z, EX01,Request,S:PSA= administrator@foobar.com ;S:FE=EX01.FOOBAR.LOCAL;S:URL=https://ex01.foobar.local:444 /ecp/proxyLogon.ecp (https://owa.foobar.com/ecp/y.js)

With the following (Linux/UNIX) command logs can be searched for relevant entries:

grep -ir “proxylogon“ ./ECP/Activity | sort -n

For the German version of this post, see here.

SD-Speicherkarten

Schutz gegen Ransomware: HiSolutions Selbsthilfe Offline-Backup

von Enno Ewers, Clara Eichel, Daniel Jedecke & Andreas Salm

Ransomware ist und bleibt die größte IT-Bedrohung für Unternehmen und öffentliche Einrichtungen. Alle Daten eines digitalen Systems können im Angriffsfall verschlüsselt werden – das schließt Sicherungskopien mit ein. Häufig werden diese sogar zuerst vom Angreifer gelöscht, gesperrt oder manipuliert. 

Beim klassischen Backup ist das oberste Ziel die schnelle Wiederherstellbarkeit für „normale“ Fehlfunktionen, daher sind die Backup-Daten oft „live“ im Zugriff durch die IT-Infrastruktur – und damit auch durch den Angreifer. Ein Ransomware-sicheres Backup verweigert dem Angreifer diesen Zugriff.

Aktuell ist die Gefahr durch HAFNIUM/ProxyLogon besonders groß.

Unser Selbsthilfe-Dokument Offline-Backup soll praktische Möglichkeiten zur Umsetzung insbesondere für kleine und mittlere Unternehmen aufzeigen.

HiSolutions entdeckt neue HAFNIUM/ProxyLogon IoCs

von Daniel Jedecke, David Fuhr und Vincent Rockenfeld

For English version of this advisory, please see here.

Bei der großen Menge an forensischen Untersuchungen zum Thema HAFNIUM/ProxyLogon, die wir aktuell durchführen, haben wir in mehreren Fällen gesehen, dass die Microsoft-Tools (Skripte bzw. Safety Scanner aka MSERT) nichts finden, da im HttpProxy-Log kein ProxyLogon zu sehen war, während der Zugriff im ECP Activity Log nachvollziehbar war.

Hier die Indikatoren für eine Kompromittierung (IoCs):

./ECP/Activity/ECPActivity_39844_20210303-1.LOG: 2021-03-03T06:43:32.531Z ,EX01, ,S:FE=EX01.FOOBAR.LOCAL;S:URL=https://ex01.foobar.local:444 /ecp/proxyLogon.ecp (https://owa.foobar.com/ecp/y.js);S:Bld=15.1.2106.2;S:ActID=def0-b0e6-2342-5e2c-23a8ff1962a1;Dbl:WLM.TS=0

./ECP/Activity/ECPActivity_39844_20210303-1.LOG: 2021-03-03T06:43:32.963Z, EX01,Request,S:PSA= administrator@foobar.com ;S:FE=EX01.FOOBAR.LOCAL;S:URL=https://ex01.foobar.local:444 /ecp/proxyLogon.ecp (https://owa.foobar.com/ecp/y.js)

Mit folgendem (Linux-/UNIX-)Befehl lassen sich die Protokolle auf die interessanten Einträge hin durchkämmen:

grep -ir “proxylogon“ ./ECP/Activity | sort -n

Um den Austausch von Researchern zu fördern und damit sich andere schneller schützen können, haben wir unsere Erkenntnisse auch auf Twitter geteilt. Siehe z. B. https://twitter.com/Jedi_meister/status/1372287075547017218

Bitte beachten Sie weiterhin unsere stetig aktualisierte HAFNIUM/ProxyLogon Selbsthilfe und unsere Empfehlungen zum Monitoring.

HAFNIUM/ProxyLogon: Akute Angriffswelle auf Microsoft Exchange

Seit in der Nacht zum Mittwoch, 3. März 2021, das Microsoft Threat Intelligence Center (MSTIC) über eine akute Angriffswelle auf Microsoft Exchange Server informiert hat, haben IT-Organisationen weltweit alle Hände voll zu tun, die ausgenutzten Schwachstellen (inkl. ProxyLogon) zu schließen, eine mögliche Kompromittierung abzuchecken und ggf. Aufräumarbeiten durchzuführen.

Auch wenn Microsoft umgehend Out-of-band Updates veröffentlich hat, wurde schnell klar, dass die vier beschriebenen Schwachstellen in Kombination bereits für zielgerichtete Angriffe verwendet wurden und vielerorts die Möglichkeit boten und bieten, Daten abzugreifen oder weitere Schadsoftware zu installieren.

https://blogs.microsoft.com/on-the-issues/2021/03/02/new-nation-state-cyberattacks/

Zu den Sofortmaßnahmen gehört neben dem umgehenden Einspielen der Patches die sofortige Deaktivierung der über HTTPS erreichbaren Dienste (OWA, ECP, UM, VDir, OAB). Eine erste Überprüfung auf Kompromittierung kann mittels eines von Microsoft bereitgestellten Scriptes oder durch Scannen des Microsoft Exchange Server mit dem Microsoft Support Emergency Response Tool (MSERT) erfolgen. Um die Möglichkeit der Angriffsdetektion zu verbessern, sollte außerdem die Protokollierung der Exchange-Server und des Active Directory ausgeweitet werden.

Im Falle der Detektion einer Kompromittierung (z. B. einer Webshell) müssen das System und je nach Berechtigungen ggf. weitere Systeme wie etwa das Active Directory näher untersucht werden. Hier muss darauf geachtet werden, ob es zum besagten Zeitraum zu Kontenerstellung, vermehrten Zugriffen oder ähnlichen Auffälligkeiten gekommen ist.

Unsere Handlungsempfehlungen

Weitere Ressourcen

Hold My BIA: Vergiftet oder erfroren – Welche ist die KRITISchste Dienstleistung?

Zurzeit lohnt aus dem Gesichtspunkt KRITIS ein langer und tiefer Blick in die USA, wo sich innerhalb kürzester Zeit zwei Szenarien ereigneten, die einige jüngst noch als Panikmache bezeichnet hätten: Während dieser Tage ein Wintereinbruch in Texas und Umgebung Millionen von Haushalten von der Stromversorgung abschneidet, konnte Anfang Februar ein Angriff auf die Wasseraufbereitung in Florida abgewehrt werden, der potenziell das Trinkwasser der Kleinstadt Oldsmar hätte vergiften können.

Aus Security-Sicht scheint vor allem der zweite Fall interessant, aber es macht durchaus Sinn, beide im Vergleich anzuschauen. In der texanischen Katastrophe kommen mindestens vier Dinge zusammen: Unsere wohlbekannte Abhängigkeit vom Strom als der Grund-kDL (kritische Dienstleistung) des Informationszeitalters, die ebenfalls wohlbekannt wackelige Infrastruktur in diesem Bereich in den USA und anderswo, die Zunahme der Volatilität in komplexen Systemen, die wir zu sehr aus dem Gleichgewicht bringen (Stichwort Klimawandel) sowie möglicherweise auch ein stückweit der Hochmut lokaler Machthabender, zu meinen, das eigene Grid besser getrennt vom Rest des Landes betreiben zu können – so viel Föderalismus gibt es nicht einmal bei uns. Trotzdem müssen wir zugeben, dass es nicht möglich ist, eine Infrastruktur gegen jedes „Black Swan“-Risiko abzusichern. Oder sollte Nigeria jetzt schneesichere Kraftwerke bauen? Die Notfallbehandlung im südlichen US-Bundesstaat scheint wiederum, soweit sich das aus der Ferne beurteilen lässt, durchwachsen zu laufen.

Oldsmar hingegen scheint Stoff für Horrorfilme zu bieten: Ganze Kleinstadt ausgelöscht durch böse Terror-Hacker! Also fast! Dabei wird hier eher umgekehrt ein Schuh draus: Dass auch im Bereich Wasser Fernwartung inzwischen die Regel ist und Teamviewer und Co. nicht allerorten sicher konfiguriert sind, hat sich herumgesprochen. Insofern war das Szenario erwartbar – und wurde auch erwartet und entsprechend behandelt. Auf IT-Ebene ist der Angriff zwar geglückt, wurde aber umgehend detektiert (durch Admin) und wäre auch sonst aufgefallen, bevor ein Schaden hätte entstehen können (durch Technik und Prozesse). Aus Sicherheitssicht also ein nützlicher Wakeup-Call oder wenigstens Reminder – aber der unfreiwillige Red-Teaming-Test wurde in jeder Hinsicht bravourös bestanden.

Also doch den Blick wieder nach Texas: Wir müssen auch in der IT aufpassen, dass wir uns in möglichst wenige Situationen hineinmanövrieren, wo die Komplexität außen steigt (Was ist unser „Klimawandel“?*), während wir innen zu viel Energie mit Altlasten („technical debt“) binden. Auch das wird immer wieder einmal schiefgehen – siehe diese Digests der letzten Jahre – aber wir sollten die Gesamttrajektorie im Blick behalten.

https://www.wired.com/story/oldsmar-florida-water-utility-hack/

* Siehe z. B. Lesetipp „Security, Moore’s law, and the anomaly of cheap complexity“.

Lesetipps Februar 2021

A Corporate Anthropologist’s Guide to Product Security 

Was kann ein Unternehmensanthropologe zur Security beitragen? Viel, stellt sich heraus, jedenfalls wenn er Alex Gantman heißt und es um Produktsicherheit geht. Der Bericht seiner jahrzehntelangen Arbeit am Thema Product Security ist nicht nur erhellend, sondern auch äußerst nützlich als Handreichung.

https://www.linkedin.com/pulse/corporate-anthropologists-guide-product-security-alex-gantman

Security, Moore’s law, and the anomaly of cheap complexity

Der (Ex-)Sicherheitsforscher Thomas Dullien alias Halvar Flake hat bereits 2019 einen bisher zu Unrecht weniger beachteten Vortrag zum Thema der ökonomischen Gründe für den Komplexitätsanstieg, der bekanntlich der Hauptfeind der Security ist, gehalten.

Video: https://www.youtube.com/watch?v=q98foLaAfX8 

Folien: https://docs.google.com/presentation/d/181WFEcKiOiIDiWygVk2WGActldWUkAPiPsn5U4KKN_g/mobilepresent?slide=id.p1 


Katastrophenarm(ee): Ich war‘s nicht – Cyberwars!

Zwanzigmal „Cyber“ in einem Artikel? Ob das ein Qualitätsmerkmal sein kann, sollten Sie anhand meiner letzten Security-Kolumne in der Zeitschrift iX am besten selbst beurteilen. 
Teaser: „COVID-19 hat eine Überlebensquote von 98–99% – Ebola schnaubt verächtlich – und ­einen Reproduktionsfaktor von lediglich 2–3, worüber die Masern nur lachen können. Was die aktuelle Pandemie so tragisch macht, ist genau die Kombination aus exponentiellem Wachstum, das aufgrund aufwendiger Detektion nicht „billig“ zu begrenzen ist, und nicht vernachlässigbarer Todesrate. Ebola und SARS waren zu tödlich und auffällig, um sich weit verbreiten zu können, Corona haut genau in einen Sweet Spot von tödlich genug für ein weltweites Massaker, aber auch harmlos genug, um sich von uns immer weiter herumtragen zu lassen.“ Und ja, es geht (auch) um Security.

https://www.heise.de/select/ix/2021/1/2031711062675348992