Sven Strittmatter & Robert Seedorff 18. August 2020

Security-Test-Driven Company

Es liegt in der Verantwortung jedes Einzelnen in einem Projekt oder Team, etwas für Security zu tun. © Adobe: Halfpoint / stock.adobe.com / 318585564 — © Adobe: Halfpoint

Security ist wichtig. Security wird immer wichtiger. Da ist man sich heutzutage einig. Mittlerweile gibt es sogar eine Cyber-Wehr [1], die ernst gemeint und nicht nur eine reine Verballhornung ist.

Warum ist Security heutzutage so wichtig?

Manche würden sagen, dass Security schon immer wichtig war. Es gab allerdings Zeiten, da war das nicht so. Da hat man diesen Kostenfaktor gerne mal unter den Tisch fallen lassen. Begründet wurde das oft mit dem Argument, dass das System nur intern benutzt wird und von "außen" ohnehin niemand darauf zugreifen kann. Damals konnte man sich noch hinter Firewall und VPN verstecken und man musste sich schon richtig Feinde machen, um gehackt zu werden.

Was hat sich also verändert? Heutzutage wird man nicht unbedingt explizit von Hackern angegriffen – wobei man als großes und bekanntes Unternehmen natürlich immer ein lohnendes Ziel ist. Vielmehr steht man sehr oft einfach im Streufeuer von großflächigen Angriffen. Nehmen wir das sehr prominente Beispiel von WannaCry und der Deutschen Bahn im Jahr 2017: Hier hat sich kein "böser Hacker" vorgenommen, speziell die Deutsche Bahn zu hacken. Hier haben die Hacker einfach ein bisschen Software geschrieben, die alles angriff, was nicht bei drei auf den Bäumen war. Die Deutsche Bahn war nur ein Opfer von vielen.

Es vergeht kaum ein Tag, an dem nicht in den einschlägigen Security-News von "Sicherheitsschwankungen" berichtet wird. Hier eine Firma "runtergefahren" und die Mitarbeiter in Zwangsurlaub geschickt, dort eine Behörde "gecryptet" und nichts geht mehr. Ganz zu schweigen von den vielen Datenreichtümern. Anfang dieses Jahres stellte Microsoft Unmengen Kundendaten ins Internet, weil man vergessen hatte, ein Passwort zu setzen [2]. Warum ist dieses Beispiel so interessant? Microsoft macht nicht gerade wenig im Bereich Security. Sie haben eigene Teams und Abteilungen für Security und Budgets, von denen der Durchschnitts-Programmierer in seinen Projekten nur träumen kann. Früher war der Konzern dafür bekannt, notorisch unsichere Software zu produzieren. Mittlerweile ist Microsoft, was Security angeht, ganz weit vorne und investiert massiv in diesen Bereich. Und dennoch passiert genau dort so etwas. Scheint also gar nicht so einfach zu sein, das mit der Security.

Zu guter Letzt steigt langsam auch der öffentliche Druck. Denn immer mehr dieser prominenten Beispiele werden nicht mehr nur in den Fach-, sondern auch in den Publikumsmedien diskutiert. Der Zwischenfall der Deutschen Bahn mit WannaCry etwa schaffte es in alle gängigen Medien. Sind dann noch personenbezogene Daten betroffen, kommt schnell auch noch die DSGVO mit empfindlichen Strafen ins Spiel. Der Reputationsverlust in solchen Fällen ist immens. Konnte man früher durchaus noch argumentieren, dass ein möglicher finanzieller Verlust viel geringer ist als die Kosten, ein altes Legacy-System zu patchen, so funktioniert das heute oft nicht mehr. Niemand möchte dort Kunde sein, wo Kreditkartendaten abhanden kommen, mit denen Kriminelle im Darknet wiederum Straftaten begehen könnten.

Die Lösung: Enterprise IT-Security

Dabei scheint eigentlich klar zu sein, wie man mit dem Problem umzugehen hat. Es gibt diverse Standards wie ISO 27001, TISAX, BSI Grundschutz uvm. Die muss man in seiner Organisation einfach nur ausrollen und dann ist alles gut. Soweit die Theorie.

Dazu eine kleine Anekdote: Ein Kollege hat viele Jahre als externer Software-Architekt bei einem großen Deutschen Konzern gearbeitet. Irgendwann interessierte ihn, wie das denn eigentlich mit dem Thema Security im Konzern geregelt sei. Er bekam einen Termin beim CISO und dieser legte ihm einen 400 Seiten dicken Papierstapel vor, mit dem Kommentar: "Hier sind alle unsere Prozesse dokumentiert. Wir sind sicher!" Nur um es sich nochmal auf der Zunge zergehen zu lassen: Dieser Kollege hatte bereits viele Jahre in diesem Konzern Software gebaut, ohne jemals Kenntnis von diesem Papierstapel gehabt zu haben. Nicht, dass dieser zu etwas nütze gewesen wäre, außer eventuell damit einen Hacker zu erschlagen.

Zur Klarstellung: Viele dieser Standards haben durchaus vernünftige und brauchbare Bestandteile. Es reicht allerdings nicht, sie wie einen Cargo-Kult in Papierberge zu gießen, die man dann in den Schrank legt und ignoriert. Und nein, das Ganze in einem Wiki zu zementieren, ist nicht besser.

Das Problem mit diesem Top-Down-Ansatz ist, dass in der Regel von einer zentralen Stelle aus vorgegeben wird, wer wie zu arbeiten hat, um sicher zu sein. Konkret entstehen dabei dann Richtlinien wie zum Beispiel:

Welche Software darf ich installieren?
Wo darf ich meine Dokumente ablegen?
Welche Bibliotheken und Frameworks darf ich benutzen?
Was für Hardware darf ich benutzen?
Hinzu kommen dann noch diverse Checklisten, die bei On-/Off-Boarding, Ausschreibungen, Projektstart oder Release abgearbeitet werden müssen.

Das mag noch funktionieren, wenn man eine mittelgroße Organisation hat, die eine Handvoll Produkte herstellt und man bereit ist, dafür dedizierte Mitarbeiter einzustellen, welche diese Richtlinien erstellen und pflegen. Aber als Großkonzern oder Dienstleister ist das schlicht unmöglich. Es gibt einfach zu viele unterschiedliche Technologie-Stacks und Produkte. Mit den heutigen Arbeitsweisen (Agil, DevOps etc.) wird das auch nicht weniger. Ein Entwickler-Team das agil arbeitet, releast vielleicht gar nicht mehr, sondern alle Änderungen gehen direkt live in Produktion, nachdem sie durch die CI/CD-Pipeline durch sind. Wer soll da noch Checklisten durchgehen und wann?

Oder sehen wir uns Microservice-Architekturen an: Hier kann theoretisch jedes Team einen komplett anderen Technologie-Stack wählen. Wenn man für jeden dedizierte Vorgaben vorhalten möchte, ist die Skalierbarkeit schlichtweg nicht möglich. Was passiert beispielsweise, wenn ein Team, das in zweiwöchigen Sprints arbeitet, beschließt, ab dem nächsten Sprint nicht mehr nur Java, sondern auch Go zu verwenden? Kann der CISO so schnell alle notwendigen Vorgaben liefern? In der Regel nicht, es sei denn, ihm steht eine sehr große Abteilung zur Verfügung. Soll das Team andererseits monatelang auf eine Freigabe warten? In der heutigen Zeit, in der die Time-to-Market geschäftskritisch sein kann, ein eher unrealistisches Szenario.

Es gibt zwei Szenarien, was in diesem Unternehmen passieren wird:

Die Teams arbeiten nach vorgefertigten Kochrezepten. Sie benutzen genau das, was ihnen vorgegeben wird. Dementsprechend findet wenig Innovation und Weiterentwicklung statt; der Frustrationslevel in den Teams steigt. Der Sicherheit ist das auch selten zuträglich, denn in so einem Umfeld werden Teams nur selten Bibliotheken oder Systeme freiwillig updaten.
Die Teams arbeiten einfach an den Vorgaben vorbei. Es entsteht die sogenannte Schatten-IT, in der niemand weiß, was tatsächlich an Infrastruktur, Software oder Komponenten im Einsatz ist. Jeder macht mehr oder weniger, was er will und die Richtlinien und Vorgaben verkommen zu einem nutzlosen Papiertiger.

In beiden Varianten arbeitet die zentrale Security-Abteilung weiter an ihrem Papierstapel mit Prozessvorgaben und geht davon aus, dass alle Richtlinien befolgt werden und man sicher sei. Das Management weiß in der Regel gar nicht, dass man unter Umständen nur einen Klick von der Katastrophe entfernt ist. Dort geht man davon aus, dass man alles im Griff hat: Wir haben ja die Security-Abteilung, die Zertifizierung und den Papierstapel, alles quantifizier- und nachweisbar. Und dann klickt jemand auf den falschen Dateianhang und die Firma steht still.

Das Skalierungsproblem

Nichtsdestotrotz sind Standards wie ISO27001 oder BSI-Grundschutz durchaus hilfreich. Sie geben Unternehmen einen roten Faden für das Ablegen grundlegender Informationen und Vorkehrungen vor, um für den Ernstfall gewappnet zu sein. Es macht zum Beispiel durchaus Sinn, Notfallpläne zu haben, die man abarbeiten kann. Nicht so praktisch ist es, wenn man sich dann erst Gedanken macht, wenn der Notfall eingetreten ist.

Das Problem mit diesen Standards ist, dass die Umsetzung meist eine sehr statische Ausprägung hat. In der Regel wird eine Gruppe von Beschäftigten in einem Unternehmen damit beauftragt, eine Zertifizierung "durchzuführen". Diese Gruppe lässt sich beraten und erfährt, dass es ganz viele Dinge dokumentieren muss: Inventar, Richtlinien, Lizenzen, Notfallpläne, Risikobewertungen uvm. Dann läuft man los und schaut, was man so alles im Unternehmen hat und versucht, das zu dokumentieren. Das Problem ist nur, dass sich die Realität, die man versucht abzubilden, weiterentwickelt und verändert. Heutzutage agieren in Unternehmen so viele verschiedene Stakeholder mit unterschiedlichen Anforderungen miteinander, Technologie-Stacks und Infrastruktur verändern sich laufend und das in zunehmender Geschwindigkeit. Bis die Dokumentation fertiggestellt ist, hat sich die Realität bereits verändert und die Dokumentation ist bereits bei ihrer Fertigstellung veraltet. Man müsste diese Dokumente permanent anpassen und pflegen. In der Version von 2005 der ISO27001 war das sogar explizit mit dem PDCA-Zyklus beschrieben. Allerdings erfolgt diese kontinuierliche Anpassung nur sehr selten. Da der Aufwand, die Dokumente und Prozesse initial zu erstellen so hoch ist, dauert das oft Monate. Dieser wird maximal zum nächsten Audit hin wieder angefasst. Ein weiteres Problem in diesem Zusammenhang besteht darin, dass die Richtlinien und Arbeitsanweisungen für Entwickler-Teams sehr restriktiv – mit Quality-Gates und Review-Boards – definiert werden, in der Hoffnung, dadurch das Fehlerpotential und so die Angriffsfläche zu verringern. Das führt allerdings wiederum dazu, dass Projektlaufzeiten explodieren, weil die zentrale Security-Abteilung zum Flaschenhals für die Organisation wird.

Aus den Bereichen Agile und DevOps kennen wir zwei essenzielle Konzepte, um dieses Problem zu bewältigen: Automatisierung und Dezentralisierung.

Nehmen wir als Beispiel die Inventarisierung der IT-Infrastruktur (Rechner, Server, Smartphones, Switches etc.). Die Existenz dieser Geräte kann man automatisiert mit Netzwerkscans erfassen und die Daten ablegen. Zudem kann man, wenn man IaC verwendet, auch das als Quelle für ein Inventar benutzen, da man hier die Infrastruktur ohnehin bereits codifiziert abgelegt hat. Der entscheidende Punkt ist, dass man das automatisiert. R. Montesino und S. Fenz haben in ihrem Konferenz-Paper "Information security automation: How far can we go?" bereits 2011 dargestellt, dass man 37 Controls aus der ISO27001 automatisieren könnte [3]. Das ist gut ein Drittel.

Der andere entscheidende Punkt ist Dezentralisierung. Wenn ein Unternehmen eine zentrale Security-Abteilung hat, die als Gatekeeper alles prüfen und dokumentieren muss, dann ist diese Abteilung zwangsläufig der Engpass. In der Agile Community existiert schon sehr lange ein Trend, solche Querschnittsaufgaben in die einzelnen Teams zu integrieren. So ist es im agilen Umfeld üblich, keine QA-Abteilung zu haben, sondern die Test-Engineers direkt in die Entwicklungsteams zu integrieren. Das kann man für Security genauso machen, z. B. durch die Einführung der Rolle des Security-Champions oder gleich des DevSecOps-Engineers. Eine zentrale Security-Abteilung macht nur insofern Sinn, dass sie die Teams dabei unterstützt, diese Rollen auszubilden und sie zu befähigen, aktiv an der Umsetzung und Definition von Security-Standards mitzuwirken. Nur so kann gewährleistet werden, dass der Bedarf an Expertise im Bereich Security skaliert und die Teams auch im Bereich Security autonom agieren können. Zudem schafft dies auch eine höhere Akzeptanz, da Security nicht irgendwo weit entfernt im Elfenbeinturm stattfindet, sondern direkt im Team.

Security muss gar nicht so schwer sein

Nehmen wir das Beispiel von WannaCry: Es standen im März 2017 Patches von Microsoft zur Verfügung [4]. Hätte man diese eingespielt, wäre man geschützt gewesen. Selbst für Windows-Versionen, die eigentlich aus der Wartung waren, hat Microsoft Patches ausgeliefert. Die Deutsche Bahn hat es Mitte Mai getroffen [5]. Andere noch viel später. Man hätte also einfach nur Patches einspielen müssen. Dazu muss man wahrlich kein Security-Spezialist sein, sondern man muss davon Kenntnis haben und dann auch handeln.

Patches nicht auszurollen, ist heutzutage keine Option mehr.

Das Gleiche gilt auch für Bibliotheken und Frameworks. Alle gängigen Tech-Stacks bieten Möglichkeiten, um Dependencies zu managen und upzudaten. Man muss es nur regelmäßig tun. Damit hat man schon viel gewonnen. Ja, manchmal machen Updates Dinge kaputt. Aber wenn man zehn Jahre mit Updates wartet und dann mehrere Major-Versionen hoch gehen muss, wird es nicht einfacher werden. Hier sollten eventuell auch Dienstleister und Zulieferer in die Pflicht genommen werden. Dass ein Hersteller einer Software kritische Sicherheitslücken nicht zeitnah patchen kann, ist heutzutage schlicht nicht mehr hinnehmbar!

Es liegt in der Verantwortung jedes Einzelnen in einem Projekt oder Team, etwas für Security zu tun. Um einen OWASP Dependency Checker in einen Build zu integrieren, der veraltete Bibliotheken reportet, bedarf es keines großen Budgets vom Management. Auch Bugfix-Releases von Bibliotheken und Frameworks einzuspielen ist meist kein großer Aufwand. Man muss es nur tun. Wer in einer Stabsstelle für Security arbeitet, sollte daher aufhören, den Teams bis hinunter zur Build-Nummer vorzuschreiben, welche Versionen von Bibliotheken oder Tools sie verwenden dürfen. Damit wird mehr Schaden angerichtet, als Nutzen für Security generiert. Updates müssen eingespielt werden – und zwar immer! Innerhalb von einer Woche, dann ist das noch vertretbar. Wirklich gut ist eine Organisation dann, wenn sie kritische Sicherheitsupdates innerhalb von 24 Stunden ausrollt. Wenn ein Update eine Software kaputt macht, dann muss man die Software fixen. Patches nicht auszurollen, ist heutzutage keine Option mehr.

Ausreden zählen hier nicht, denn einem Angreifer ist es egal, ob

das eine Third-Party-Bibliothek ist,
das Budget ausgegangen ist,
das kein Business-Value bringt,
der Launch-Termin morgen ist,
das andere Team zuständig ist oder
der Dienstleister dafür bezahlt werden möchte.

Er wird Sie einfach hacken und die Daten raus tragen oder die Firma stilllegen.

Aber nicht nur Updates sind wichtig. Auch sollte geprüft werden, ob man in irgendeiner Art verwundbar ist, z. B. durch Fehlkonfiguration. Manchmal hat man auch irgendwo noch Dienste laufen, die veraltet sind oder gar nicht mehr gebraucht werden. Es gibt unzählige Tools, die dabei helfen und mit denen man seine Systeme auf eventuelle Sicherheitsprobleme testen kann. Ein paar Empfehlungen:

Nmap: Das Standardwerkzeug zum Scannen im Netzwerk. Damit können Sie Ihre Server prüfen, ob Ports offen sind, die evtl. nicht offen sein sollten [6].
Amass: Mit diesem Scanner können Sie sehen unter welchen Sub-Domains man im Internet erreichbar ist, um dann zu überlegen, ob das alles so seine Richtigkeit hat oder ob da Systeme dabei sind, die besser nicht im Internet erreichbar sein sollten [7].
SSLyze: Mit diesem Scanner können Sie prüfen ob Ihr SSL/TLS korrekt konfiguriert ist [8].
Nikto: Mit diesem Scanner können Sie Webserver auf eventuelle Schwachstellen und Fehlkonfigurationen testen [9].

Das ist nur eine sehr kleine Auswahl an Tools. Die Liste ließe sich noch beliebig lange fortführen. Im Übrigen sind das alles Tools, die auch Angreifer benutzen, um ihre Ziele auszukundschaften. Allerdings sollte der Einsatz in jedem Fall vorher abgeklärt werden. Ansonsten kann das sehr unschön enden, wenn plötzlich der Werkschutz am Schreibtisch steht, weil man einen Port-Scan gemacht hat.

Abb. 1: Architekturüberblick. © iteratec GmbH

Wie die secureCodeBox entstand

Nun ist das mit den Tools leicht gesagt. Zum Einen muss man sich in jedes Tool erst einmal einarbeiten. Zum Anderen muss man das Tool immer manuell ausführen. Aus diesem Problem heraus entstand die Idee, das besser zu machen. Die Tools sollten einfach orchestriert in die Build-Pipelines integriert werden können. So entstand die OWASP secureCodeBox [10].

Die Idee ist relativ simpel: Man orchestriert gängige Security-Scanner mit einer selbst entwickelten Engine. Diese Engine verteilt zu scannende Ziele – etwa die URL einer WebApp – an die gewünschten Scanner und aggregiert die Ergebnisse. Alle Komponenten sind in einer Container basierten Microservice-Architektur umgesetzt. Das bedeutet auch, dass sich jeder beliebige Security-Scanner integrieren lässt, solange man ihn in einem Container lauffähig bekommt.

Die secureCodeBox ist als Open Source auf GitHub veröffentlicht und ein offizielles OWASP Incubator Project [11,12].

YATI – Yet Another Tool to Ignore

Somit ist die Lösung klar: Jedes Projekt muss einfach nur die secureCodeBox in ihrem Build-Prozess einsetzen, dann wird alles gut. Wir ernennen dann noch in jedem Projekt einen Security Champion und definieren ein Reifegradmodell. Anschließend produzieren wir nur noch sichere Software...

Zugegeben, das klingt ähnlich wie der Ansatz mit der Enterprise IT-Security. Der Unterschied ist lediglich, dass hier nicht riesige Papierstapel produziert werden, sondern den Teams von zentraler Stelle aus ein ziemlich kompliziertes Tool vor die Füße geworfen wird. Natürlich fanden diese das alle erst mal ganz großartig. Aber auch die secureCodeBox ist keine One-Click-Lösung. Das Phänomen ist bekannt: ein Tool wird ausgerollt, man lässt es gegen sein Projekt laufen und es kommen Unmengen Findings raus, mit denen man sich genauer beschäftigen sollte. In der Realität bedeutet das, es wird nie passieren. So war das auch bei der secureCodeBox. Bis auf ein paar enthusiastische Teams wurde sie kaum eingesetzt. Die Lernkurve und der damit verbundene Aufwand schienen viel zu hoch.

Wir drehen den Spieß um

Hieraus entstand die Überlegung: Wieso scannen wir mit der secureCodeBox immer nur ein dediziertes Projekt? Wieso betrachten wir nicht unsere gesamte Firma als Projekt das wir kontinuierlich scannen? Seitdem scannen wir permanent unsere gesamte Firma von innen und außen. Dabei finden wir auch immer wieder mal spannende Dinge, sowohl in der Infrastruktur, als auch in den Projekten der Teams.

Ein wichtiger Unterschied zu vorher ist, dass das Security-Team jetzt aktiver mit den verantwortlichen Teams sprechen und das Problem erklären kann. Man kann das Thema nicht so einfach "wegklicken" wie das Tool im Browser, sondern es wird so lange nachgehalten, bis das Problem verstanden und behoben ist. Wichtig dabei ist, Fragen zu beantworten und direkt Hilfestellung zum Beheben der Probleme zu geben. So lernen die Beteiligten, wie sie Security umsetzen können und erleben, dass es oft gar nicht so schwer ist. Dadurch entsteht eine höhere Akzeptanz als durch eine nichtssagende Meldung in einem anonymen Tool.

Security ist kein Zustand, sondern ein Prozess.

Dadurch, dass die identifizierten Probleme transparent in die Teams getragen werden, findet auch dort eine breitere Diskussion darüber statt. Wir haben die Erfahrung gemacht, dass sich dadurch noch mehr Leute für das Thema Security interessieren und in Summe die Security-Awareness steigt. Manchmal entsteht daraus sogar eine kleine Challenge: Wer kann sich am besten vor den Angriffen schützen? Wenn sich Entwicklungsteams schon zur Entwicklungszeit und in der gesamten Entwicklungsumgebung nicht mehr per se "geschützt" fühlen können, dann steigt auch die Motivation und das Eigeninteresse, entsprechende Schutzmaßnahmen zu treffen, egal ob im Firmennetzwerk oder in der Cloud.

Was haben wir gefunden?

Durch diese Vorgehensweise konnten mehrere sicherheitsrelevante Themen identifiziert werden, wie z. B.:

Eine VoIP-Telefonanlage, deren Web-UI kein TLS unterstützte und durch die per Man-in-the-Middle-Attacke, Credentials der User hätten mitgeschnitten werden können. Nach Gesprächen mit dem Hersteller haben jetzt alle seine Kunden ein sichereres System mit TLS, sofern sie Updates einspielen.
Eine drei Jahre alte Jira-Confluence-Installation, die nur "übergangsweise" für ein oder zwei Monate bestehen sollte. Alle Projektbeteiligten gingen davon aus, dass die gar nicht mehr da sei – war sie aber doch.
Eine virtuelle Maschine in einem Netzsegment, die seit längerem ungenutzt mit 32 GB RAM und 16 Kernen lief und eigentlich nur Strom verbrauchte.
Hosts, die veraltete Algorithmen für SSH konfiguriert hatten.
Diverse Tomcat-Example-Apps auf Entwicklungsumgebungen.

Alles Dinge, die relativ leicht zu beheben sind. Man muss es eben nur tun. Aber noch viel wichtiger: man muss erst einmal wissen, dass man diese Probleme hat. Wenn man sich nicht auf Checklisten und Papierberge mit Richtlinien verlassen möchte, dann ist das Einzige, was hier hilft Automatisierung: Man muss die Security-Ziele, die man in seinem Unternehmen erreichen möchte, regelmäßig automatisiert prüfen und Abweichungen sofort beheben.

Wir sind noch nicht fertig

Natürlich nicht, denn mit Security wird man nie fertig sein. Denn Security ist kein Zustand, sondern ein Prozess, in dem man sich kontinuierlich vorwärts bewegen muss. Man muss permanent den Ist-Zustand mit dem Ziel-Zustand abgleichen und aus den Abweichungen geeignete Maßnahmen ableiten und umsetzen. Daher gibt es noch weitere Pläne mit der secureCodeBox:

Wir sind der Meinung, dass dieser Ansatz, die Firma permanent mit Scans zu erfassen und zu testen, der einzige praktikable Weg ist, die immer schneller wachsende Komplexität in der IT-Landschaft eines Unternehmens zu beherrschen. Statt klassisch im Nachhinein zu prüfen und zu dokumentieren, fahren wir einen aktiven Ansatz wie beim Test-Driven Development. Unsere Test Cases sind Security- und Netzwerk-Scans verbunden mit einer Baseline an akzeptablen Ergebnissen. Alle gefundenen Abweichungen werden bewertet und bei Bedarf wird die Baseline angepasst oder die Abweichung behoben. Natürlich ist das gerade am Anfang ein durchaus schmerzhafter Prozess. Wenn man anfängt, nach Problemen zu suchen, dann wird man sie auch finden und man kann die Augen nicht mehr einfach vor ihnen verschließen. Dabei muss man viele Beteiligten aus ihrer Komfortzone holen und für die Probleme sensibilisieren. Ein Aufwand, der sich aber definitiv lohnt.

Quellen