Guten Morgen!
Nach dem kurzen Intermezzo mit dem Mini-Briefing zur sicheren SPS-Prorgammierung kommt hier das gewohnt ausführliche Schutzhelmbriefing, um Sie in den August zu begleiten.
Es war ein ereignisreicher Monat - das sehen Sie daran, dass es oft mehr als einen Lesestoff-Link pro Thema gibt. Das passiert nur, wenn ich mich partout nicht für einen davon entscheiden kann.
Noch etwas zieht sich wie ein roter Faden durch das August-Briefing: MITRE ATT&CK. Das Framework wird breit genutzt und ist Inspiration für viele gute neue Ideen. Wir widmen uns diesem Ideenfeuerwerk explizit und außerdem werden Sie ATT&CK auch in anderenPunkten implizit wiederfinden. Das sieht vielleicht pädagogisch wertvoll aus, war aber tatsächlich gar keine Absicht - ATT&CK bekommt wirklich so viel "mindshare" wie der Engländer sagen würde. Aber lesen Sie selbst.

In dieser E-Mail gibt es Neuigkeiten und Lesestoff zu folgenden Themen:

1. Security in der SPS-Programmierung: Projekt ist jetzt online
2. EU gibt Cybersecurity-Strategie bekannt, USA warnt vor Angriffen auf OT
3. INL Test Effect Payloads: Frischer Wind für Security Tests?
4. Ideenfeuerwerk rund um ICS ATT&CK
5. NAMUR Open Architecture (NE 175) veröffentlicht
6. Angriffs- und Verteidigungspotenziale: F5, SIGred und Defending Exchange
7. Leseperlen zum Schluss: Security aus CEO-Sicht, Security aus IAM-Sicht

1. Security in der SPS-Programmierung: Projekt ist jetzt online

Im Mini-Briefing hatte ich es schon angekündigt: Am 29.07. haben Dale Peterson, Jake Brodsky und ich den initialen Entwurf der Top 20 Secure PLC Coding Practices vorgestellt.
Wäre das Webinar ein „echtes“ Seminar gewesen, wir hätten wohl Stühle dazustellen müssen. Mit knapp 200 Teilnehmern kam in der Diskussionsrunde keine Langeweile auf. Wer es verpasst hat: Das Webinar wurde aufgezeichnet. Hier können Sie es die nächsten 90 Tage anschauen.

Wer lieber liest als hört: Eine Einführung in das Top 20 Secure Coding Practices-Projekt finden Sie in den Lesestoff-Links und meinem Blog, wahlweise auf Deutsch oder Englisch.

Nun ist es an Ihnen: Der aktuelle Stand ist unter top20.isa.org frei verfügbar - die einzige Voraussetzung ist das Anlegen eines Accounts (mehr als Nutzername und E-Mail-Adresse müssen Sie nicht angeben). Die Inhalte liegen auf einer Discourse-Plattform, um das Kommentieren und Bearbeiten einfacher zu machen. Kurz nach dem Webinar hatten wir 100 registrierte Accounts. Ich würde mir ein Loch in den Bauch freuen, wenn Sie auch dabei wären.

A propos Kommentieren:
Viele von Ihnen haben schon Rückmeldungen und Verbesserungsvorschläge an mich direkt geschickt. Das ist großartig! Noch komme ich auch hinterher, die Dinge einzuarbeiten - aber das wird Grenzen haben. Hier daher noch einmal die Ermutigung: Die Plattform ist zum Kommentieren gedacht, so etwas wie "zu harte Kritik" gibt es nicht und selbst wenn: Reibung erzeugt Wärme, und wir haben die Initialversion deswegen online gestellt, damit sich viele an ihr reiben. Kaputt machen können Sie sowieso nichts. Auf gehts!

Weil ich weiß, dass es sich in der Muttersprache manchmal flüssiger diskutiert, wird es noch eine deutschsprachige Version des Webinars geben (auch zu für Europäer angenehmerer Zeit) - und bei Bedarf deutschsprachige gemeinsame Kommentierungssitzungen zu den Top 20 im Nachgang.

Der Termin für das deutschsprachige Webinar ist am Donnerstag, 06. August, um 10 Uhr. Für die Anmeldung einfach auf diese Mail antworten. Einen deutschsprachigen Einstieg in die Secure PLC Coding Practices finden Sie im Lesestoff-Link.

2. EU gibt Cybersecurity-Strategie bekannt, USA warnt vor OT-Angriffen

OT-Security hat es im vergangenen Monat sowohl auf unserem als auch auf dem amerikanischen Kontinent auf die politische Agenda geschafft.

Fangen wir jenseits des großen Teichs an: In den USA sorgte eine Meldung der CISA (Cybersecurity & Infrastructure Security Agency) vom 23. Juli für Aufsehen. Allerdings ist die Meldung wenig konkret und warnt vor einer "continues willingness to conduct malicious cyber activity agains critical infrastructure".

Ebenso unkonkret bleiben naturgemäß die empfohlenen Gegenmaßnahmen: Härtung, Netzpläne, Asset-Inventar, Monitoring, Incident Response. Aha.
"Im Westen nichts Neues" möchte man sagen...Link zum CISA Alert s.u.
[Nebenbemerkung: Die CISA nutzt seit einiger Zeit MITRE ATT&CK, um seine Informationen über Angriffe zu systematisieren].

Schauen wir also nun diesseits des großen Teichs, also nach Europa.
Die ENISA (European Union Agency for Cybersecurity) hat am 17. Juli ihre Strategie veröffentlicht, um ihr Mandat gemäß EU Cybersecurity Act zu erfüllen. Das 24-seitige Strategiepapier formuliert naturgemäß eher abstrakte Ziele. An einigen Stellen braucht es aber dann doch überraschend wenig Fantasie, um sich vorzustellen, was sich ändern soll.
Geschmacksproben? Ich zitiere:

Strategic Objective S02: Cybersecurity as an Integral Part of EU Policies
"We want to achieve

• Proactive advice and support to all relevant EU-level actors bringing in the cybersecurity dimension in policy development lifecycle through viable and targeted technical guidelines
• Cybersecurity risk management frameworks that are in place across all sectors and followed throughout the cybersecurity policy lifecycle."

Strategic Objective S05: High Level of Trust in Secure Digital Solutions
"We want to achieve

• Cyber secure digital environment across the EU, where citizens can trust ICT products, services and processes through the deployment of certification schemes in key technological areas."

Wer den EU Cybersecurity Act kennt, weiß es schon:
Die Reise geht zu mehr Security-Regularien und -Zertifizierungen.
(Die aktuellen Entwicklungen zum Thema Security-Zertifizierungen werden wir uns übrigens in einem der kommenden HardHats-Briefings anschauen).

3. INL Test Effect Payloads: Frischer Wind für Security Tests?

Eines meiner persönlichen Highlights von der diesjährigen S4 ist jetzt online: Ginger Wright vom staatlichen US-Forschungsinstitut Idaho National Laboratory (INL) mit ihren "Test Effect Payloads".
Die Grundidee ist, basierend auf INL's Security-Engineering-Methodik "Consequence-based, Cyber-informed Engineering" (CCE) Testfälle abzuleiten. Man muss sich diese Testfälle als Szenarien vorstellen, die kritische Funktionen gefährden können.

Ginger stellt das Konzept mit dem Ziel vor, um die Reaktion auf Security-Vorfälle (Incident Response) zu üben und verbessern. Die Idee könnte aber genauso helfen, Security Tests systematischer und reproduzierbarer zu machen - als Ergänzung zum klassischen Pentest, der ja gezielt NICHT gegen bestimmte Testfälle testet.

Über das von Ginger Wright vorgestellte Konzept gibt es öffentlich so gut wie nichts zu lesen (wer etwas findet, gern Link an mich!). Bis dahin ist das S4-Video die einzig öffentlich verfügbare Dokumentation der Idee - Sie finden es im untenstehenden Link.

4. Ideenfeuerwerk rund um ICS ATT&CK

Seit das ATT&CK for ICS Framework vor einem guten halben Jahr online gegangen ist, hat es viele Ideen für Ergänzungen, Mappings und ähnlich strukturierte Konzepte gegeben.
Grund genug, einen Überblick über die spannendsten Ideen zu geben.

Zunächst aber in aller Kürze das Wichtigste zu ATT&CK: Das Ziel der ATT&CK-Frameworks ist es, Security-Angriffsmethoden zu systematisieren und einzuordnen. Mit seiner Systematik ist es nicht nur ein eindrucksvolles Nachschlagewerk - es entmystifiziert Security-Angriffe auch, weil es ihnen die Unübersichtlichkeit und scheinbare Unberechenbarkeit nimmt und zeigt: Es sind oft dieselben, im Kern einfachen Schritte, die zu einem erfolgreichen Angriff führen.

Das Framework beruht auf breiter Mitarbeit und somit auch Akzeptanz der (ICS-)Security-Community - das ist eine seiner größten Stärken.

2013 hat die US-amerikanische Organisation MITRE erstmals das ATT&CK-Framework, damals für Windows-PCs, entwickelt. ATT&CK for ICS ist eine Adaption des MITRE ATT&CK Frameworks für Industrial Control Systems (Link siehe Link 2 in der untenstehenden Linksammlung).

ICS ATT&CK besteht - wie jedes ATT&CK-Framework - aus sogenannten “Tactics” und “Techniques”.
Tactics strukturieren einen Angriff in einzelne Schritte, die einen bestimmten Zweck verfolgen, z.B. “Initial Access” (Erstzugriff), “Discovery” (Ausspähen von Angriffszielen) oder “Lateral Movement” (Weiterbewegen im Netzwerk). Einige Tactics sind ICS-spezifisch, etwa “Impair Process Control”.
Techniques sind Wege, eine bestimmte Tactic in die Tat umzusetzen, so kann der Erstzugriff beispielsweise über eine Kompromittierung einer Engineering Workstation, einen Phishing-Anhang oder Wechseldatenträger geschehen. Für einen Angriff müssen natürlich nicht alle “Tactics” durchlaufen werden - vielmehr reichen oft ausgewählte Schritte.

Rund um ATT&CK hat es in den letzten Monaten ein wahres Ideenfeuerwerk gegeben. Versuchen wir einen Überblick:

1. MITRE hat Sub-Techniques für ATT&CK eingeführt, also spezifischere Techniques. Das macht nicht nur den Detailgrad der Techniques konsistenter, sondern ermöglicht auch viel differenziertere Betrachtung von Angriffsmöglichkeiten.
   Beispiel: In der Tactic "Credential Access" ist eine der Techniques "Brute Force". Sie hat nun die Sub-Techniques "Credential Stuffing", "Password Cracking", "Password Guessing" und "Password Spraying".
   Für jede Sub(-Technique) gibt es Wiki-Seiten, in denen man die Unterschiede zwischen den Techniques erfährt, aber auch Möglichkeiten, einen solchen Angriff zu erkennen oder verhindern.
   Link zum neuen ATT&CK-Framework s. Link 1 in der untenstehenden Linksammlung.
   Hier geht's zum MITRE-Blogpost rund um die neuen Sub-Techniques.


2. Das Atomic Threat Coverage (ATC)-Projekt rund um Daniil Yugoslavskiy hat sich das ehrgeizige Ziel gesetzt, ATT&CK zu operationalisieren. Dazu werden im GitHub-Repository automatisierbare Hilfsmittel für die Verteidigung gegen ATT&CK Techniques gesammelt, etwa Signaturen, Logging-Policies, Härtungsrichtlinien und Incident Reponse-Playbooks.
   Der Incident-Response-Teil hat den an ATT&CK angelehnten Namen RE&CT, und es ist auch nach einem ähnlichen Prinzip aufgebaut: Für die typischen Incident Response-Phasen (Preparation, Identification, Containment, Eradication, Recovery und Lessons Learned) finden sich jeweils typische Response Actions. Die Idee ist, diese zu Playbooks für spezifische Situationen zu kombinieren. Lesenswert! Das Projekt ist wie ATT&CK community-basiert und sucht Beitragende - siehe Link 3 in der untenstehnden Linksammlung.


3. Isiah Jones und Otis Alexander haben außerdem vorgeschlagen, den einzelnen ATT&CK for ICS-Techniques passende Maßnahmen der ISA/IEC 62443 zuzuordnen. Isiah skizziert in seinem Blog, wie das auf Systemebene (also ISA/IEC 62443-3-3) und auf Kompoenentenebene (also ISA/IEC 62443-4-2) aussehen könnte.
   Eine gute Idee - und ein Haufen Arbeit mit zwei beweglichen Zielen (ATT&CK auf der einen, die IEC 62443 auf der anderen Seite). Mehr unter Link 4 in der untenstehenden Linksammlung.

5. NAMUR Open Architecture (NE 175) veröffentlicht

Wenn wir Montagsmaler spielen würden und der Ratebegriff wäre die NAMUR Open Architecture (NOA), müsste ich nicht lange überlegen: Die Automatisierungspyramide mit dem zusätzlichen Kanal an der Seite ist einprägsam.

Gut für eine Architektur, die als Referenz für die Sensordatennutzung für Industrie-4.0-Anwendungen dienen soll. Die dazugehörige NAMUR-Empfehlung NE 175 ist im Juli veröffentlicht worden.

Die Grundidee ist einfach erklärt: Statt über den üblichen, umständlichen Weg durch die Ebenen der Automatisierungspyramide sollen Daten für Monitoring und Optimierungen durch einen Seitenkanal an allen üblichen Ebenen vorbei übertragen werden.
Und damit über diesen unkomplizierten neuen Kommunikationskanal nicht auch total unkompliziert schädliche Daten im Feld ankommen, soll der Seitenkanal eine Einbahnstraße sein: Nur aus der Felebene (oder einer anderen Ebene der Pyramide) hinaus, nicht aber hinein - technisch sichergestellt durch die "NOA-Diode".

Wer hier direkt an Datendioden denkt, muss gebremst werden: Wie das Konzept der rückwirkungsfreien "NOA-Diode" technisch realisiert werden soll, lässt die NE175 offen. Die NOA-Diode ist überhaupt die einzige Stelle, an der Security im NOA-Konzept Erwähnung findet.

Hoffnung macht eine weitere NAMUR-Empfehlung, die noch in Arbeit ist: NE177 "NAMUR Open Architecture – NOA Diode and Security". Das "and" lässt hoffen, dass es mit der Forderung nach rückwirkungsfreier Kommunikation nicht getan ist.

Eine Kurzfassung der NE 175 ist auf den Seiten der NAMUR abrufbar - siehe Lesestoff-Link.

6. Neue Angriffs- und Verteidigungspotenziale: F5, SIGred und Defending Exchange

Ich bin sicher, die "dicken Brummer" unter den Schwachstellenmeldungen haben Sie diesen Monat locker mitbekommen, deswegen bringen wir's kurz und schmerzlos hinter uns:

1. SIGred oder CVE-2020-1350 heißt das neue CVE-Kind aus dem Hause Microsoft. Es betrifft die Microsoft-Implementierung von DNS. Wenn Sie Active Directory haben, sind Sie also wahrscheinlich betroffen.
   Weil die Schwachstelle Remote Code Execution ermöglicht, bekommt sie die saubere Höchstpunktzahl im CVSS-Score: 10.0. Metasploit-Module, mit denen man die Schwachstelle automatisiert nutzen kann, haben dementsprechend nicht lang auf sich warten lassen. Was tut man da? Patchen. Infos im ersten Lesestoff-Link.


2. CVE-2020-5902 betrifft F5 BIG IP - ein zentrales, mächtiges Infrastrukturprodukt für Funktionen wie Loadbalancing, VPN, DNS, PKI und die Terminierung von Verschlüsselung.
   In Kürze: Nochmal Remote Code Execution, nochmal CVSS 10.0, nochmal bereits bekannte Metasploit-Module (nicht, dass die nötig wären, denn die notwendigen Kommandos passen in ein paar Zeilen).
   Was tut man da? Patchen, klar. Vom F5 verwaltete Schlüssel zurückziehen und erneuern.
   Das hilft aber nur kurzfristig.
   
   Oder, wie Thomas Fricke und Manuel Atug im Blogpost der AG-KRITIS zur F5-Schwachstelle schreiben, für langfristige Abhilfe muss sich etwas Grundlegendes ändern:
   "Es ist aufgrund der Banalität der Schwachstelle anzunehmen, dass eine Sicherheitslücke dieses Ausmasses bei sorgfältigen, geordneten und kontinuierlichen Sicherheits- und Abnahmetests nicht übersehen worden wäre."
   Link im Lesestoff 2.


3. Im Lesestoff 3 (auf Englisch) beschreibt Joe Slowik von Dragos außerdem lesenswert Worst-Case-Szenarien zur Ausnutzung der F5-Schwachstelle nicht nur zum Nachteil der Firma, der der betroffene F5-Server gehört, sondern auch seiner Kunden oder Lieferanten.


4. Und hier auch mal eine gute Nachricht: Microsoft hat einen neuen Blogpost mit Schutzmaßnahmen für Exchange-Server verfasst. Ganz ohne konkrete Schwachstelle als Trigger, einfach so.
   Und übrigens: Mit Referenzen auf MITRE ATT&CK-Techniques.
   Link im Lesestoff 4.

Randnotiz:
Übrigens erreichte mich nach dem letzten Briefing die Bitte, statt "Schwachstelle" lieber "Angriffsmöglichkeit" zu schreiben - denn manches, was aus Security-Sicht eine "Schwachstelle" ist, ist aus funktionaler Sicht durchaus ein Feature. Das hat Charme, aber ich breche mir ein wenig die Finger dabei, wie Sie in der Überschrift sehen. Wie verheiratet sind Sie eigentlich schon so mit dem Wort "Schwachstelle"?

7. Leseperlen zum Schluss: Security für CEOs (kurz), Security für IAM-Manager (lang)

In die Restwoche und den Restmonat entlasse ich Sie dieses Mal mit Lesestoff, den Sie an Ihr Zeitkontingent anpassen können:

Auf die Schnelle:
Dieser hervorragende Twitter-Thread von Robert Graham (@ErrataRob) fasst lesenswert die CEO-Perspektive auf Security zusammen. Wichtige Erinnerung für alle in der Security-Blase, egal ob Vollzeit oder als Extra-Rucksack. Vorgeschmack:
"The only thing more broken than how CEOs view cybersecurity is how cybersecurity experts view cybersecurity. We have this flawed view that cybersecurity is a moral imperative, that it's an aim by itself."
Link zum ganzen Text unten im kurzen Lesestoff.

Kaffee holen und zurücklehnen:
Über den notPetya-Ransomware-Vorfall bei Maersk 2017 ist viel gesagt und geschrieben worden. Der Text "Maersk, me & notPetya" von Gavin Ashton ist trotzdem lesenswert.

Warum? Gavin Ashton war zum Zeitpunkt des Vorfalls Service Owner für IAM, Identity and Access Management, bei Maersk, oder in anderen (seinen eigenen, selbstkritischen) Worten: Er war derjenige, unter dessen Verantwortung die Maßnahmen fallen, die die schnelle Ausbreitung von Würmern verhindern können. Allen voran sieht er Versäumnisse im Management von privilegierten Nutzerkonten:

"70 % is a big number. That’s how many of these events start with a compromised identity. So, you really, really want to manage your identities well. You want to manage their access well. Every single week another sorry tale appears of another organisation taken out by the same process: Identity compromise, digital foothold, lateral movement, privileged creds, lost enterprise or stolen data. This is how it happens time and time again."

Der Text ist lang, aber nicht länglich und außerdem ausgeruht und erkennbar praxisgereift. Er bringt starke Argumente dafür vor, dass ein Security-Vorfall so oft nicht auf den ausgeklügelten, fancy Angriffen beruht, gegen die man ohnehin nichts tun kann. Und das ist eine gute Nachricht, denn sie bedeutet, dass die Gegenmaßnahmen nichts Kompliziertes sind, und außerdem nichts, was in einem "big bang" geschafft werden muss: Das Security-Ziel definieren und die Systeme Stück für Stück diesem Ziel näherbringen, das - schreibt Gavin Ashton - hätte Maersk schon geholfen.

Ich gebe Ihnen noch ein letztes Zitat mit auf den Weg in den August - den Rest finden Sie im langen Lesestoff-Link. (Ganz unten im Text gibt's übrigens sehr praktische, konkrete Hinweise für Berechtigungsmanagement).

"The eye opener for me was, we weren’t even the target. [...] So be under no illusion, you might not believe yourself to be at much risk, but it might not even be about you."

Stay secure!
Sarah Fluchs