https://www.spiegel.de/netzwelt/netzpolitik/gehackt-an-weihnachten-bsi-warnt-vor-besonderer-gefahr-an-den-feiertagen-a-a35eb9ba-f2af-48a5-900d-ca2a8e0791f6

Sie finden uns in Halle 7, Stand 510. Wir freuen uns auf den persönlichen Austausch rund um das Thema Datensicherheit und der einfachen Anwendung von Application Whitelisting.

Application Whitelisting ist nichts Neues. Wie der Name schon andeutet ist Whitelisting der umgekehrte Ansatz zu Blacklisting. Blacklisting als Begriff ist weniger geläufig als die Produktgattung die sich auf dieses Prinzip stützt – Virenscanner.

Das Whitelisting von Anwendungen geht den umgekehrten Weg und verweigert standardmäßig die Ausführung von Anwendungen, die nicht explizit als "bekannt und vertrauenswürdig" auf der Whitelist bekannt sind. Dieser "Default Deny"-Ansatz bietet aus vielen Gründen ein wesentlich höheres Schutzniveau als der etablierte Blacklisting-Ansatz für Antivirus Produkte.
Hauptgrund für den Einsatz von Application Whitelisting (im folgenden nur noch als AWL abgekürzt) aber ist und bleibt, dass bösartiger Code, der noch nie zuvor gesehen wurde, verhindert werden kann. So genannte "Zero-Day"-Angriffe. Ein Virenscanner der eine Blacklist bereits bekannter Schädlinge oder Verhaltensweisen führt, kann diese neuen Schädlinge nicht identifizieren.

Jeder vernunftbegabte Mensch fragt sich jetzt: Wenn Whitelisting so viel sicherer ist als Blacklisting, warum ist es dann nicht so weit verbreitet wie Blacklisting-Lösungen, also Virenscanner?

Die Antwort ist einfach. Eine Blacklisting-Lösung lässt zwar Schadcode ungehindert ins Netzwerk wenn sie einen schlechten Job macht, aber blockiert niemals gutartigen, unbekannten Code. Beispielsweise Teile des Betriebssystems. Wenn ein Whitelisting Produkt einen schlechten Job macht, sind die Systeme vielleicht extrem sicher, aber es wird die Nutzbarkeit des Systems beeinträchtigen, indem es unbekannten aber vertrauenswürdigen Code blockiert. Die meisten Menschen haben daher die einfache Handhabung von Blacklisting gegenüber der unumstritten besseren Sicherheit von Whitelisting bevorzugt.

Ein weiterer Grund, warum AWL nicht sehr verbreitet ist, sind frühe AWL-Lösungen aus den 90er Jahren. Diese waren wie beschrieben oft eher ein Hindernis im Alltag und haben dem Prinzip Whitelisting einen bis heute schlechten Ruf eingebracht. Moderne AWL-Lösungen werden daher bis heute an der schlechten Leistung der Lösungen aus dem letzten Jahrtausend gemessen. Moderne Whitelisting Lösungen können aber wesentlich automatisierter operieren und verursachen im Alltag heute weder ungewollt blockierte Software noch den oft gefürchteten Mehraufwand. Dieser Artikel soll diese und andere Vorurteile sowie Missverständnisse widerlegen, die selbst von Sicherheitsexperten immer noch gegen die Technik vorgebracht werden. Beim Blacklisting wird jede neue Datei auf einem System überprüft. Erkennt der Virenscanner eine Datei als schädlich, wird die Ausführung verhindert.

Vorurteil Nummer 1:

Whitelisting Produkte von Drittanbietern sind überflüssig, da die Technik bereits in modernen Betriebssystemen kostenlos integriert ist.

Der wohl bekannteste integrierte Whitelisting Service ist der AppLocker von Microsoft. Mit einer Windows Server Lizenz können Sie auch stolzer Besitzer einer Application Whitelisting Lösung werden. Wenn Sie also keine andere "Default-Deny" Technik nutzen, die Teil Ihres Sicherheitskonzepts ist, dann können Sie dieses Tool in Betracht ziehen, um die Lücken zu schließen, die Virenscanner konzeptbedingt hinterlassen. Die Verwendung integrierter Lösungen ist aus Sicht des Gesamtkonzepts viel sinnvoller als diese Angebote einfach zu ignorieren.

Das Problem ist jedoch, dass diese Lösungen nur schwer zu handhaben und aktuell zu halten sind. Die Verwaltung dieser Tools erfordern oft, dass der IT-Administrator alle Programme identifiziert, die erlaubt sein sollten. Auf einem Standard Betriebssystem sind das Tausende von Dateien. Änderungen und Ergänzungen der Whitelist brauchen Zeit und sind nicht direkt verfügbar. Die manuelle Verwaltung der Liste von erwünschten und vertrauenswürdigen Anwendungen, kann eine Belastung darstellen, die den Zugewinn an Sicherheit obsolet macht. Kritiker von AWL führen diese Mankos integrierter Whitelisting Tools oft als Grund an, keine AWL-Lösungen zu verwenden.

Die Frage aber bleibt: Wenn moderne AWL Lösungen so viel besser sind, warum ignoriert die überwiegende Mehrheit der IT-Administratoren und Sicherheitsexperte sie und verwendet nur Blacklisting zur Absicherung der Systeme? 

Vorurteil Nummer 2:

Application Whitelisting ist kompliziert zu handhaben und zu zeitaufwändig

Zugegeben bei tausenden von Anwendungen für einen einzigen PC klingt das nachvollziehbar. ständig ändern Updates einzelne Anwendungen oder das gesamte Betriebssystem wird gepatcht. Genau das ist eines der Kernprobleme, die moderne AWL-Lösungen schon längst gelöst haben. Denn so aufwändig es klingt, es ist ein sehr gut lösbares Problem. Moderne AWL-Produkte sind sehr geschickt darin, die relevanten Daten auf einem System zu identifizieren, Änderungen automatisch zu genehmigen und die Whitelist-Datenbank entsprechend aktuell zu halten. In einer ordentlichen AWL-Lösung ist es selten nötig einzelne Dateien der Whitelist manuell hinzuzufügen oder gar zu löschen. Änderungen, wie z.B. das Installieren eines neuen Softwarepakets bringen diese Lösungen nicht mehr dazu alles als unbekannt zu blockieren. Moderne AWL-Lösung macht das Management der Whitelist so automatisch und zeitsparend wie möglich.

Vorurteil Nummer 3:

Application Whitelisting setzt jeden Nutzer der Gnade der Administratoren aus.

Einige AWL-Lösungen folgen dem Ansatz, dass alle Entscheidungen über das, was erlaubt oder verweigert werden soll, ausschließlich in den Händen von IT-Administratoren oder Sicherheitsexperten liegen. Jedoch ist das nur in sehr statischen Umgebungen oder für PCs mit festem Anwendungsumfang überhaupt umsetzbar.

Die meisten Whitelisting Produkte ermöglichen heute, dass Aktionen die ein Nutzer ausführt sich auch mit AWL vereinbaren lassen. Dabei wird nicht dem Nutzer vertraut, sondern sogenannten Reputationsservices. Führt ein Nutzer also eine unbekanntes Programm aus, so blockiert die Whitelist die Ausführung nicht direkt, sondern versucht anhand von Informationen z.B. aus der Cloud, zu erkennen ob diese Anwendung tatsächlich schon als schädlich oder gutartig bekannt ist. In den meisten Fällen können nämlich für neue Anwendungen automatisch Freigaben erteilt werden, ohne dass der Nutzer dies mitbekommt oder in seiner Arbeit gehindert wird. Sind keine entsprechenden Erkenntnisse vorhanden oder handelt es sich tatsächlich um Schadcode wird die Software natürlich trotzdem blockiert.

Der Administrator der AWL-Lösung ist bei der Vorkonfiguration aber auch immer in der Lage, bestimmte vertrauenswürdige Anwendungen von vornherein von diesem Prozess auszuschließen. Auch wenn diese prinzipiell vertrauenswürdig sind. Spiele und andere unerwünschte Software kann so vom automatischen Lernen ausgeschlossen werden. Versucht der Endbenutzer so verbotene Software zu installieren, wird ihm das nicht gelingen, auch wenn die Software gutartig ist. Dies alles kann unter Beibehaltung der standardmäßigen "Default-Deny" Schutzfunktionen, die das gesamte System schützt, durchgeführt werden.

Vorurteil Nummer 4:

Entwickler können ihrer Arbeit nicht mehr nachgehen

Der Großteil der Dateien, die Nutzer im Rahmen ihrer Arbeit erstellen und bearbeiten, sind lediglich Daten die nicht ausführbar sind. Entwickler jedoch erstellen ausführbaren Code als Teil ihrer täglichen Arbeit. Unbekannter ausführbarer Code ist aber genau das, was AWL-Lösungen blockieren. Die vorher genannten Reputationsdienste nützen hier nichts, denn woher soll die gerade erstellte Software dort bekannt sein? Bei richtiger Vorgehensweise können auch Entwickler AWL zum Schutz ihrer Systeme verwenden, ohne ihre normale Arbeit zu beeinträchtigen.

Der einfachste Weg, Entwickler zu integrieren, ist den generierten Code zu signieren. Wenn ein Entwickler zum Beispiel Visual Studio für die Entwicklung verwendet, bedeutet das Vertrauen in Signatur mit der Visual Studio jedem kompilierten Code unterschreibt, dass jeder so signierte und ausführbare Code automatisch zur Whitelist-Datenbank hinzugefügt und zur Ausführung freigegeben werden kann.

Andere Lösungsansätze sind sogenannte Lernbenutzer. Das Anstarten einer unbekannten Software wird statt mit dem angemeldeten Nutzer einfach mit einem speziell berechtigten AD Nutzer durchgeführt. Alles was im Nutzerkontext dieses Lernbenutzers ausgeführt wird darf auch auf die Whitelist aufgenommen werden.

Eine komplett andere Möglichkeiten bietet die physische Trennung von Entwicklungsumgebungen vom Rest des Netzes. In einer DMZ braucht man keinen Schutz durch die AWL Lösung.

Vorurteil Nummer 5:

Application Whitelisting verlangt die komplette Konzipierung eines Netzwerks zu ändern.

Auch bei diesem Vorurteil kann nur wiederholt werden: für eine schlechte AWL Lösung mag das zutreffen. Ein gutes Whitelisting Produkt arbeitet nahtlos mit der bestehenden Netzwerk- und Hardwarearchitektur zusammen und integriert sowohl Softwareverteilung als auch Systemmanagement. Denn eine Whitelisting Lösung muss lediglich mit den verwendeten Tools bekannt gemacht werden, alles andere geschieht dann automatisch.

Vorurteil Nummer 6:

Application Whitelisting und bestehende Antivirus Lösungen können nicht parallel betrieben werden. 

Es gibt keinen Grund, warum Whitelisting und das Blacklisting von Virenscannern nicht parallel arbeiten sollten. Es wird sogar häufig die Empfehlung ausgesprochen beide zur gleichen Zeit zu verwenden. AWL schützt proaktiv vor Zero-Day-Angriffen, die Virenscanner andernfalls durchlassen würden. Der Virenscanner kann von der Whitelist blockierte Schadsoftware schließlich von den Endpoints entfernen, ohne dass irgendjemand dafür einen Finger rühren muss. Aus technischer Sicht sollten alle AWL-Lösungen neben allen Blacklist-Lösungen gut funktionieren. Ob es tatsächlich sinnvoll ist beide parallel zu betreiben ist wahrscheinlich eine Frage der Einstellung und der finanziellen Mittel. Der Schutz den Whitelisting bietet macht den Virenscanner überflüssig.

Vorurteil Nummer 7:

Application Whitelisting kann durch Skripte leicht umgangen werden.

Das ist einfach nur falsch. Jedes moderne AWL Produkt wird die Fähigkeit beinhalten, bestimmte Programme (Interpreter) in der Nutzung zu beschränken. Diese Option wird Application Control genannt. Nur bestimmte User wie Administratoren beispielsweise sind über Application Control in der Lage einen Interpreter wie PowerShell überhaupt auszuführen. Alle anderen User können das für das Skript notwendige Programm erst gar nicht ausführen. Es gibt sogar Lösungen die sämtliche Skripte verweigern können, jedoch wird diese Option nur in den seltensten Fällen überhaupt aktiviert, da das Blockieren von Skripten mit unter zu Problemen führt, die vorher nicht abzusehen sind. Skripte stellen überdies auch keine permanente Bedrohung für einen Endpoint dar, sobald der betroffene PC auf dem ein schadhaftes Skript läuft neu gestartet wird, ist auch das Skript wieder inaktiv.

Vorurteil Nummer 8:

Anwendungen die bereits auf der Whitelist stehen können genutzt werden um das Whitelisting zu umgehen.

Ähnlich wie bei der potenziellen Bedrohung durch Skripte würden ernstzunehmende Hersteller einen so offensichtlichen Weg die eigene Sicherheitslösung zu umgehen nicht in ihre Produkte einbauen. Obwohl Betriebssystemkomponenten natürlich ausgeführt werden dürfen, so sind diese oft nur für den Start eines Angriffs in Verwendung. Der Code der den tatsächlichen Angriff dann ausführen soll, kann wiederum nicht gestartet werden da er unbekannt ist.

Vorurteil Nummer 9:

Application Whitelisting kann während Änderungen an Systemen umgangen werden.

Dieses Vorurteil ist auf die Funktionsweise früherer AWL-Lösungen zurückzuführen. Wenn der Administrator eine genehmigte Systemänderung vornimmt, wie z.B. die Installation eines neuen Softwarepakets, wurden die Schutzvorkehrungen vorübergehend aufgehoben, so dass die Änderungen erlernbar werden. Während dieses genehmigten Lernprozesses könnten schädliche Programme die auf die Whitelist angelernt wurden gemäß der aktualisierten Whitelist ausgeführt werden. Moderne AWL-Lösungen aber lernen nur noch die Änderungen die durch die neuen Bestandteile des Updates angefragt werden und prüfen diese gleichzeitig. Parallel ausgeführte Schadprogramme werden als unbekannt oder als bekannt und schädlich blockiert.

Vorurteil Nummer 10:

Application Whitelisting benötigt sehr viel Performance.

Diese Behauptung ist bei keiner AWL-Lösung zutreffend. Dies gilt insbesondere im Vergleich zum Overhead, der bei Blacklist-Lösungen anfällt. Damit ein Virenscanner eine Datei überprüfen kann, um diese zuzulassen oder zu blockieren, muss im einfachsten Fall der gesamten Dateiinhalt mit einer Signaturdatenbank für jede jemals identifizierte Malware-Variante abgeglichen werden. Das ist keine leichte Aufgabe und es ist das, was die CPU auf jedem System wo der Virenscanner läuft tun muss, um eine Schutzfunktion zu gewährleisten.
Damit ist noch nicht auf wesentlich aufwändigere Prüfmethoden wie Sandboxing, heuristische Analysen oder Deep Learning eingegangen worden. Zudem muss der Virenscanner immer alle Dateitypen prüfen, Sie geben also immer einen Vollzugriff auf alle Ihre Daten.

Bei AWL muss das Binary einer ausführbaren Datei nur einmalig durch durch einen Algorithmus in einen Hash umgewandelt werden. Diese Methode ermöglicht die eindeutige Identifizierung des Programms, weil jedes Programm einen anderen Hash ergibt. Man kann sich das ganze vereinfacht wie eine Quersumme vorstellen bzw. wird oft vom elektronischen Fingerabdruck des Programms gesprochen. Dieser Hash wird dann einfach an die Whitelist Datenbank gesendet und abgeglichen. Wenn der Hash nicht auf der Whitelist ist, wird das Programm welches diesen Hash erzeugt blockiert. Dieser Vorgang dauert weder lange (ca. 30ms) noch benötigt das Erzeugen des Hashs viel Performance.

Fazit

Dieser Ausschnitt an Vorurteilen beleuchtet nur die am meisten genannten im Zusammenhang mit Application Whitelisting Lösungen im Allgemeinen und seculution im speziellen. Anhand dieser 10 Vorurteile kann man allerdings sehr gut klar machen, dass diese entweder nicht mehr zutreffend oder komplett aus der Luft gegriffen sind. Inzwischen wird Whitelisting sogar als primäre Antivirus Lösung noch vor Virenscannern empfohlen, da die Bedrohungslage heutzutage eine andere Herangehensweise in der IT-Sicherheit benötigt.

In letzter Zeit werden wir immer wieder von besorgten Kunden, aber auch Interessenten und vor allem von Messebesuchern auf das Thema Fileless Malware angesprochen. Zuletzt erst auf der it-sa 2017. Daher hier ein kleiner Beitrag dazu.

Vorab:

Keine Sorge, SecuLution schützt Sie!

Damit dies aber nicht wie ein reines Marketing-Versprechen wirkt, müssen wir technisch etwas ausholen:

Prinzipiell kann keine Sicherheitslösung grundsätzlich die Ausführung von Schadcode verhindern, wenn dieser Schadcode durch Ausnutzung einer Sicherheitslücke in einer erlaubten Software nur im Speicher dieser Software ausgeführt wird, ohne eine Datei auf Platte zu speichern. Eine derartige "dateilose Infektion" war also schon immer möglich und wird auch zukünftig immer möglich sein, da die x86 und die x64 Architektur (und damit Windows) nun mal so designt sind. Aber diese Angriffe benötigen (bis heute) immer Tools wie z.B. Powershell, deren Ausführung durch SecuLution beschränkt wird, sodass im Endeffekt SecuLution auch Schutz vor allen bisher bekannten dateilosen Infektionen bietet.

SecuLution schützt Sie nach wie vor bestens.

Aber wie groß ist die Bedrohung denn überhaupt, sagen wir mal für Ihren PC Zuhause?

Gerade weil eine solche "dateilose Infektion" keine Datei auf dem Rechner ablegt, ist ein erfolgreicher Angriff immer nur bis zum nächsten Reboot aktiv, somit also temporär. Genau das kann ein Angreifer aber nicht gebrauchen, denn wenn der Rechner neu gestartet wird, ist der Angriff zunichte gemacht. Daher ist die dateilose Infektion bisher eher ein akademisches Forschungsfeld als eine realistische Bedrohung. Denn der Angreifer muss darauf trauen, dass der Anwender seinen Rechner oder die ausgenutzte Anwendung (z.B. Browser) nie neu startet. Es gibt (so gut wie) keine dokumentierten Vorfälle von erfolgreichen Angriffen mittels einer dateilosen Infektion. Einzig ein gezielter Angriff auf einige Banken, die ihre Rechner nie neu gestartet hatten, ist bekannt.

Und dieser Angriff wäre von SecuLution verhindert worden, wenn die Banken SecuLution eingesetzt hätten.

Was können Sie heute tun, um gegen eventuellen Angriffen gewappnet zu sein?

Mit SecuLution sind Sie bereits optimal geschützt, denn SecuLution bietet Ihnen als Whitelisting Lösung nicht nur den Schutz, dass sämtliche unbekannte Programme nicht gestartet werden können, sondern sorgt auch dafür, dass Angriffe, die die PowerShell verwenden, scheitern.

Zitat:

"Diese Payload startete die Powershell, die dann über WinAPI-Aufrufe Speicher reservierte und diesen mit Tools wie Meterpreter und Mimikatz bestückte."

Quelle Heise

Das alles kann unter SecuLution nicht passieren, wenn Sie unserer Empfehlung folgen und die Ausführung der Powershell per Application Control auf Administratoren beschränken: PowerShell mit Application Control einschränken

Auch wenn jetzt immer noch Zweifel bestehen, rufen wir Sie hiermit auf unsere Aussagen bezüglich der Sicherheit von SecuLution selbst nach zu prüfen. Testen Sie unsere Lösung in Ihrem Netzwerk 8 Wochen lang kostenlos und probieren Sie eigene Angriffe aus.

Wir gehen noch einen Schritt weiter. Besuchen Sie uns am 28. und 29. November auf der Cloud Security Expo in Frankfurt und bringen uns Ihre Malware auf einem USB Stick mit. Sie dürfen diese selber an einem durch SecuLution geschützten PC starten. 

Für kostenlose Eintrittskarten inkl. eines Snacks und weiterer Vorteile registrieren Sie sich bitte hier: www.cloudexpoeurope.de/seculution

18,9 Prozent der Unternehmen in Deutschland waren bereits Opfer eines Spionagefalls oder waren von Informationsabfluss betroffen.

Das Risiko von Industriespionage wird deutlich unterschätzt. Obwohl über 80 Prozent der Befragten glauben, dass das Risiko für Industriespionage weltweit ansteigen wird, glauben nur 33,7 Prozent, dass die Gefahr auch für ihr eigenes Unternehmen steigen wird.

Für die deutsche Wirtschaft entstehen durch Spionage jährlich Schäden in Milliardenhöhe. Insgesamt 64,4 Prozent aller geschädigten Unternehmen hatten auch einen finanziellen Schaden zu verzeichnen. Die Schäden reichten von 10.000 Euro bis über eine Million Euro je Schadensfall. Rechnet man dies hoch auf alle Unternehmen in Deutschland, ergibt sich eine Schadenssumme von mindestens 2,8 Milliarden Euro.

Das Ziel der Spionage waren meistens technische Innovationen bzw. das Know-how bei den Produktionsabläufen.

Bei den geschädigten Unternehmen sind die Branchen Automobil/Luftfahrzeug/Maschinenbau mit 26,9 Prozent sowie Eisen/Stahl/Metallverarbeitung mit 21,8 Prozent am häufigsten betroffen.
Der Informationsabfluss durch eigene Mitarbeiter scheint eine der größten Gefahren zu sein. Von den geschädigten Unternehmen hatten 20,3 Prozent im eigenen Betrieb einen Verrat von Interna an Unberechtigte zu beklagen.

Der Hackerangriff ist die zweithäufigste Form der illegalen Attacken auf Unternehmen. Hier meldeten 14,9 Prozent der geschädigten Unternehmen, dass ihre IT–Systeme bereits von einem eingeschleusten Spionageprogramm bzw. einem Hackerangriff betroffen waren.

Die wenigsten Unternehmen achten darauf, ihre vertraulichen Gespräche an einem geschützten Ort durchzuführen. So war das Abhören von Besprechungen mit 10,7 Prozent eine weitere sehr häufige Form der Spionage. Die geschädigten Unternehmen hatten damit einen Informationsabfluss durch einen sogenannten Lauschangriff zu verzeichnen.

In vielen Fällen ist es relativ einfach, an Details von Neuentwicklungen zu gelangen: durch Aushorchen argloser Mitarbeiter. Der richtige Ansprechpartner sowie ein paar geschickt formulierte Fragen genügen und schon gelangen die streng geheimen Informationen ungefiltert an die Konkurrenz. Durch die immer noch höchst gebräuchliche Form des „Social Engineering“ kamen 8 Prozent der betroffenen Unternehmen zu Schaden.



Diese Zahlen sind nicht aktuell, sondern aus einem Bericht aus dem Jahr 2007. Wer jetzt noch glaubt es sei besser geworden der irrt sich gewaltig. Nicht nur Ransomware Wellen wie im Jahr 2016 oder Ransomware as a Service Angebote, die es quasi jedem ermöglichen seine eigene, einzigartige Schadsoftware ohne Programmierkenntnisse über das Internet zu verbreiten, sondern auch die immer noch zum Teil völlige Arglosigkeit wie Mitarbeiter in Unternehmen und die Unternehmen selber Ihre Infrastrukturen vor Angriffen schützen, bieten nach wie vor beste Chancen um einem erfolgreichen Angriff zum Opfer zu fallen.