Forensic Investigations / Fi Blog

Fi Blog

Vereinbaren Sie jetzt einen Termin für die SPS/IPC/DRIVES Messe 2010 , die dieses Jahr vom 23. bis 25. November im Nürnberger Messezentrum stattfindet. Gerne erläutere ich Ihnen dort, wie sich die hier im Blog geschilderten Sicherheitslücken in Automatisierungssoftwarelösungen auswirken können und diskutiere Lösungswege mit Ihnen persönlich.

Ein paar Termine sind kurzfristig noch zu vergeben. Ich freue mich sehr auf ein persönliches Kennenlernen.

UPDATE 26.11.2010: Vielen Dank an alle für die interessanten und konstruktiven Gespräche auf der Messe!

Ein paar Aufnahmen von der diesjährigen SPS/IPC/Drives:

Der Stand von Vacon in Halle 1

Frequenzumrichter Vacon NX Serie

Frequenzumrichter Vacon NX Serie (Nahaufnahme)

Siemens glänzte mit einem riesigen Stand in Halle 2 ...

...zumindest für Präsentation ist offenbar immer Geld genug vorhanden.

Eine Bildgalerie mit weiteren Impressionen von der Messe finden Sie hier:


Die Datenbanksicherheitslücke in WinCC (Video 2.1) ist offenbar nicht in jeder Situation von Remote ausnutzbar. Unter Windows XP ist der TCP-Port des SQL-Servers in der Standardkonfiguration durch die Windows-Firewall geschützt, was die Ausnutzung des Konfigurationsfehlers zumindest von aussen verhindert.

Wurde der Port jedoch geöffnet, beispielsweise um mit einem ERP-System auf die Daten zuzugreifen, ist besondere Vorsicht geboten.

Unter Windows XP scheint die Datenbanksicherheitslücke deshalb normalerweise 'nur' zu einer lokalen Privilegieneskalation (EoP) zu führen. Unter den vielen noch laufenden älteren Windows 2000-Systemen, die aufgrund der dort noch nicht standardmäßig vorhandenen Windows-Firewall normalerweise ungeschützt sind, kann die Lücke von Remote ausnutzbar sein.

Bewertung

Unter Windows 2000 muss die Lücke nach wie vor als 'kritisch' eingestuft werden, da standardmäßig kein Firewall installiert ist, was sie von Remote ausnutzbar machen könnte. Unter Windows XP ist die Gefahr immer noch als 'hoch' anzusehen, da sie einem Angreifer Administrator-Rechte verschaffen könnte. Ursache für das Problem sind die in beiden Fällen mit vollen 'sysadmin'-Rechten ausgestatteten Benutzer "WinCCAdmin" und "WinCCConnect". Dies entspricht wohl nicht der üblichen 'Best Practice' oder den Empfehlungen von Microsoft . Da der primäre Infektionsweg von Stuxnet ('LNK-Bug') geschlossen ist, besteht zumindest durch die bisher bekannten Varianten keine akute Gefahr.

Vorsichtsmaßnahmen

Überprüfen Sie unbedingt, ob der SQL-Server TCP-Port auf Ihren Systemen von außen erreichbar ist. Eventuell können Sie den Zugriff auf diesen Port auf dem System oder zumindest auf einer vorgelagerten Hardware-Firewall blockieren, um die Angriffsfläche zu vermindern. Falls bei Ihnen keine SQL-Kommunikation über TCP/IP stattfindet, können Sie mit dem SQL Server-Konfigurations-Manager auch die Bindung des SQL-Servers an TCP/IP entfernen. Achten Sie in jedem Fall darauf, eventuell erforderliche Kommunikation nicht zu blockieren.

Wenn Sie den Port nicht schließen können, beschränken Sie den Zugriff auf die Systeme, die tatsächlich Zugriff benötigen (z.B. ERP/BI Serversystem(e) statt ganzem Subnetz).

Achten Sie sorgfältig darauf, keine infizierten Rechner oder Datenträger in Ihr Netzwerk einzuschleppen.

Weitere Informationen auch zur Codeausführung beim Öffnen von Projekten (Video 2.2) folgen in den nächsten Tagen. Sie können auch unseren RSS-Feed nutzen, sich registrieren und über Änderungen benachrichtigen lassen , oder persönlich mit uns in Kontakt treten. Demnächst hier auch ein SCADA-Security-Forum.

UPDATE 10.12.2010: Weitere Informationen zur Codeausführung beim Öffnen von Projekten finden sie hier .

WinCC Datenbank-Bug: Schweregrad nach CVSS-Standard

Berechnung des Schweregrads für eine typische Automatisierungs-Umgebung nach dem CVSS -Standard (Ihr CISO sollte Ihnen helfen können, diese Metriken und Vektoren zu interpretieren, weitere Informationen finden Sie auch hier ):

  • CVSS Overall Score Windows 2000: 8.9 /10
  • CVSS Overall Score Windows XP (SQL Server Port closed=default): 8.4 /10
  • CVSS Overall Score Windows XP (SQL Server Port open): 8.7 /10

Im Zuge der Auswertung der Stuxnet-Angriffe auf SIEMENS SIMATIC WinCC und PCS7 haben Kaspersky Labs und Symantec weitere Lücken entdeckt, die von Stuxnet ausgenutzt werden . Microsoft hat die Lücken bestätigt .

Dazu gehört der über das Netzwerk ausnzutzbare Fehler im Druckerwarteschlangendienst von Windows (CVE-2010-2729 /MS10-061 ), der mit dem September-Bulletin geschlossen wurde, sowie zwei weitere lokal ausnutzbare Lücken (Laden von Tastaturlayout Definitionsdateien, Taskplaner), die einem Angreifer höhere Rechte verschaffen und höchstwahrscheinlich mit dem Oktober-Bulletin am Dienstag geschlossen werden. Die Lücke beim Laden von Tastaturlayout Definitionsdateien (CVE-2010-2743 /MS10-073 ) wurde mit dem Oktober-Bulletin geschlossen, die weitere Lücke steht noch offen im Taskplaner (CVE-2010-3338 /MS10-092 ) wurde nunmehr mit dem Dezember-Bulletin geschlossen.

Ineffiziente Incident Response

Der SIEMENS Security Advice zu Stuxnet geht auf die nicht-ganz-so-neu bekannt gewordenen Fakten leider in keinerlei Hinsicht ein, alte Falschinformationen wurden immer noch nicht entfernt.

Der mittlerweile lange bekannte Bug (CVE-2010-2772 ) wird durch das dort angebotene 'SIMATIC Security Update' weiterhin ebensowenig beseitigt wie die von Forensic Investigations entdeckte weitere Datenbank-Lücke in WinCC (siehe Video 2.1 "Remote-Einbruch in die WinCC-Datenbank" am Ende dieses Artikels ).

Analysen haben ergeben, dass das sog. 'Sicherheitsupdate' neben der –wie im Video zu sehen– völlig unzureichenden Datenbank-Konfigurationsänderung rein gar nichts aktualisiert, sondern lediglich ein 'getarntes Desinfektions-Tool' oder ein Placebo zur Beruhigung der Kunden darstellt.

Neben diesen uns lange bekannten Mängeln, die neben Anderen, bisher nicht näher spezifizierten Sicherheitslücken bereits Ende Juli von unserer Seite an die SIEMENS AG kommuniziert wurden, kommt nun noch eine weitere von uns Mitte August aufgedeckte Sicherheitslücke dazu.

2 Stunden 200€ Software Audit von Fi bringt weitere gravierende Mängel ans Tageslicht

Ein Software Audit von weniger als 2 Stunden (entspricht Kosten <200€) konnte weitere offensichtliche Mängel zutage fördern, die Projekte infizieren können. Sowohl SIEMENS SIMATIC WinCC als auch PCS7 und weitere Tools aus der Produktfamilie sind davon betroffen. Dies führt dazu, dass Infektionen ohne Weiteres von Engineering Stationen mit Internetzugang an Anlagen-PCs ohne Internetverbindung weitergetragen werden können. Die Auswirkungen sind also durchaus mit denen des "LNK-Bug" vergleichbar, diesmal allerdings liegt die Ursache dafür einzig und allein im Verantwortungsbereich des Automatisierungsherstellers (siehe Video 2.2 "Code-Ausführung beim Öffnen eines WinCC-Projekts" am Ende dieses Artikels ). 'Proof of Concept' Demo Exploits sind auf Anfrage bei uns erhältlich führen wir Ihnen auf Anfrage vor.

Die Legende vom "Inselnetz"

Die Mär vom "Inselnetz" dürfte damit wenigstens für etwas vorausschauende Menschen ein für alle mal widerlegt sein. Selbst auf Inseln läßt man Goldschätze nicht einfach achtlos herumliegen, da es Wasserfahrzeuge, Fluggeräte und Brückenbau gibt. Diese Wasserfahrzeuge, Fluggeräte und der Brückenbau sind in unserem Beispiel Wechseldatenträger, das Roaming von Engineering Stationen, Remote Access Lösungen u.ä. Das nächste Desaster ist schon vorprogrammiert, wenn hier kein grundlegender Mentalitätswechsel stattfindet.

Sicherheit - oft ein menschliches Problem, kein technisches oder betriebswirtschaftliches

Klar hatte bereits Mark Twain (1835-1910) erkannt, dass ein Dutzend verlogener Komplimente leichter zu ertragen seien als ein einziger ehrlicher Tadel, aber es führt kein Weg daran vorbei, sich den Realitäten zu stellen. Wo Menschen arbeiten passieren Fehler, auch bei Weltfirmen.

Die Gründe dafür können vielfältig sein: Zeitdruck, Mangel an Wissen, fehlende Sorgfalt, organisatorische Defizite oder Beratungsresistenz sind nur einige der möglichen Ursachen.

Selbst wenn die gemachten Fehler als trivial und leicht vermeidbar einzustufen sind, ist es nicht unbedingt gleich als töricht einzustufen, solche Fehler zu begehen. Die wirkliche Torheit beginnt erst an dem Punkt, an dem man auf die Fehler aufmerksam gemacht wird und trotz minimalster Kosten nicht handelt, vermeintlich um sich keine Blöße zu geben. Dies birgt jedoch neben hohen Schadenersatzrisiken das Risiko eines irreparablen Vertrauensverlustes bei den Kunden.

Nahezu alle großen Hersteller haben hier mittlerweile Ihre Lektionen gelernt, sieht man einmal von Apples CEO Steve Jobs ab, der das Empfangsproblem beim iPhone unter "no issue" verbuchte und statt einer Problemlösung lieber kritische, aber wohl wahre Forumsdiskussionen löschen ließ .

Do your homework – the OTHER SIDE WILL

Bei all diesen Nachforschungen haben wir aus Kostengründen nur ein kleines bisschen an der Oberfläche gekratzt. Mit einem Etat wie es die Urheber des Stuxnet Wurms wohl hatten – ich schätze die Kosten für den Angriff auf mindestens 200.000€, 0days am Schwarzmarkt und Programmierkosten zusammen – lassen sich sicher Unmengen von Bugs aufdecken. Uns hat schon ein Tausendstel davon gereicht, um einen solchen kritischen Bug zu finden. Die Beseitigung der Mängel ist alternativlos, und von einer Person jeweils innerhalb eines Tages ohne Probleme zu erledigen – inklusive Kaffeepausen und Meetings. Ein einziges Problem durch einen Sicherheitsmangel kostet sicher ein Zigfaches. Und ein solches Problem wird kommen, da Cyberkriminelle SCADA und ICS Netze spätestens jetzt als lukratives Ziel erkannt haben dürften. Mehr zum Thema finden Sie auch in unserer Präsentation "SCADA and Industrial Control Systems (ICS) network security in 2010 ".

Die Automatisierungshersteller sollten womöglich eine Prämie von sagen wir 20.000€ pro gefundenem Bug zahlen – wenn sie Ihrer Software nur ein bisschen vertrauen. Selbst Mozilla oder Google zahlen hier 5.000€ für gefundene Fehler in Ihren Browsern – diese verteilen Ihre Software im Unterschied dazu aber kostenlos und sind in deutlich weniger sicherheitsrelevanten Bereichen beheimatet.

Um es mit den fachfremden, aber auch hier zutreffenden Worten von Phil Taylor zu formulieren:
"If you don't practice every day, the others will".

Maßnahmen

Als minimalstes Minimum sollte neben dem Update zum LNK-Bug unbedingt das schon o.g. Druckerwarteschlangendienst-Update (CVE-2010-2729 /MS10-061 ) eingespielt werden, das der Automatisierungshersteller offiziell autorisiert hat , aber leider nicht im Zusammenhang mit Stuxnet empfiehlt. Dies ist jedoch nur eine punktuelle Maßnahme.

Wie schon in einem vorigen Post berichtet fanden wir jeweils viele Dutzend Lücken, die ebenso als kritisch einzustufen waren. Ich kann allen Kunden, die kritische Infrastrukturen mit SIEMENS SIMATIC WinCC und PCS7 betreiben deshalb nur weiterhin dringendst anraten, Ihre Netze von einer neutralen Instanz auditieren zu lassen und entsprechende Maßnahmen zu ergreifen, die Gefahren für industrielle Systeme nachhaltig ausschließen .

Daneben gibt es ein "Hintertürchen" in Stuxnet, das die Infektion eines Rechners durch die gegenwärtig bekannten Varianten verhindert. Auf Anfrage stellen wir Ihnen gerne Informationen dazu bereit, um Ihre Systeme zu schützen.

Es bleibt abzuwarten, ob der Automatisierungshersteller nun nach fast 3 Monaten endlich reagiert, die Lücken schließt und vor Allem solche Vorfälle durch eine geeignete Maßnahmen nachhaltig verhindert. Unsere Lösungen hierfür liegen seit Jahren auf Halde, da sie [wie man sieht] "nicht benötigt" werden.

UPDATE 13.10.2010: Informationen zum Oktober-Patchday im ersten Absatz ergänzt.

UPDATE 03.11.2010: Wir hatten uns zwischenzeitlich dazu entschlossen aus Sicherheitsgründen die 'Proof of Concept' Demo Exploits erst herauszugeben, wenn ein entsprechender Fix verfügbar ist, Text oben entsprechend abgeändert.

UPDATE 22.11.2010: Inzwischen ist ein öffentlicher Exploit zu der Privilegieneskalation im Taskplaner erschienen. Dies war zu erwarten, da ESET ausreichend Informationen veröffentlicht hatte, um die Lücke nachvollziehen bzw. implementieren zu können. Es bleibt zu hoffen, dass dieser Bug im Zuge des nächsten 'Patch Tuesday' am 14.12. geschlossen wird.

UPDATE 14.12.2010: Die Privilegieneskalation im Taskplaner ist als nunmehr letzte von Stuxnet genutzte Sicherheitsanfälligkeit geschlossen. Entsprechende Informationen zum Dezember-Patchday im ersten Absatz ergänzt


Möglicher Hintergrund: Angriff auf iranisches Atomprogramm!?

Die Spekulationen mehrten sich in den letzten Wochen, Stuxnet sei vermeintlich ein Angriff auf das iranische Atomprogramm , vor allem geschürt durch Frank Riegers Artikel bei FAZ.NET . Rieger stellt darin die Aussage auf, Stuxnet sollte sich bereits im Januar 2009 selbst deaktivieren und sei schon lange vorher im Umlauf gewesen. Entsprechende Belege, Quellenangaben oder wenigstens Indizien fehlen aber leider. Aus anderen Quellen oder eigenen Nachforschungen kann ich diese Aussage nicht bestätigen, obwohl ich alle Berichte zu diesem Thema seit dem Bekanntwerden Mitte Juli akribisch sammle und auswerte.

Ebensowenig geht Riegers Artikel darauf ein, dass Steuerungen in Kernkraftwerken normalerweise nach dem SIL4 Standard gemäß DIN/EN/IEC 61508 ausgerichtet sind, und sich nur in einem manuell zu schaltenden Modus reprogrammieren lassen. Der Wurm würde jedoch automatisch abwarten, bis die Steuerungen in diesen Modus versetzt werden, und dann seinen Schadcode in die Steuerungen implantieren. Bei einem der mutmaßlichen Ziele, dem Kernkraftwerk in Buschehr (Google Maps ), das demnächst ans Netz gehen soll , dürfte dies während der Inbetriebsetzung in den vergangenen Monaten sicher recht häufig der Fall gewesen sein.

Ein IT-Experte des Ministeriums für Industrie und Bergbau erklärte gegenüber der iranischen Agentur Mehr News Agency , insgesamt seien über 30.000 Rechner von Industrieanlagen allein im Iran befallen worden (Wirtschaftswoche , Handelsblatt , Financial Times Deutschland , Welt , Spiegel Online u.a. hatten daraufhin berichtet).

Mehr News Agency hat inzwischen ergänzt , dass sich die Inbetriebnahme des Kraftwerks Buschehr verzögere, dies hinge laut dem Chef der iranischen Atomenergiebehörde Atomic Energy Organization of Iran (AEOI) jedoch nicht mit Stuxnet zusammen.

Stuxnet ein Machwerk des Mossad?

Ob der Angriff nun durch internationale Dienste ausgeführt wurde und tatsächlich dem iranischen Atomprogramm galt, bleibt weiter im Bereich der Spekulation. Die Darstellung, lediglich Nationalstaaten hätten die Resourcen, einen solchen Angriff zu implementieren, greift m.E. aber etwas zu kurz: Mitbewerber, Kriminelle oder Terrororganisationen wären sicher ebenso zu einem solchen Angriff in der Lage, selbst wenn die Kosten in Millionenhöhe gelegen haben sollten und hätten ebenso ein Motiv.

Die Gerüchteküche wurde noch zusätzlich angeheizt, da der Code von Stuxnet das vermeintliche Datum "19790509" enthält. Am 09. Mai 1979 wurde der Präsident der "Jüdischen Gesellschaft Teherans", der jüdisch-iranische Industrielle Habib Elghanian , von einem Erschießungskommando in Teheran hingerichtet. Dies kann auch ein reines Ablenkungsmanöver sein; in der Regel hinterlassen Autoren von Schadsoftware kaum absichtlich Hinweise, die auf Ihre Spur führen.

...oder doch von Cyberkriminellen?

Da Stuxnet befallene Rechner unter die Kontrolle der Angreifer bringt, und prinzipiell jeden beliebigen Code ausführen kann, halte ich einen 'opportunistischen' Ansatz des Angriffs ohne ein konkretes Ziel ebenfalls für sehr wahrscheinlich: erstmal infizieren, dann sehen wen man erwischt hat, und was man für Vorteile daraus schlagen kann. Wäre der Angriff 100% auf Iran gerichtet gewesen, hätte der Wurm womöglich auf die Infektion anderer Anlagen verzichtet, um das Entdeckungsrisiko nicht unnötig zu erhöhen. Ebenso könnte dies jedoch eine Ablenkungsstrategie sein, die das eigentliche Ziel verschleiern soll.

Gegen die Theorie von Cyberkriminellen als Urheber spricht die Tatsache, dass die von Stuxnet verwendete Rootkit -Technologie nicht besonders ausgeklügelt ist. Womöglich hat der Angreifer sich hier auf ein sehr laxes Management der Anlagen-Software verlassen. Das Stuxnet noch den eigentlich uralten Fehler im Server-Dienst (MS08-067 /'Conficker '-Bug) auszunutzen versucht, spricht ebenfalls dafür.

Ebenso ist der Wurm im Vergleich zu anderen im Umlauf befindlichen Schadprogrammen auch sehr leicht zu entfernen. Der Urheber hat offensichtlich damit gerechnet, dass die Mission vor dem Bekanntwerden der Schadsoftware erfolgreich abgeschlossen sein würde, und er sich nicht vehement gegen seine Entfernung zur Wehr setzen müsste.

Die insgesamt vier in Stuxnet enthaltenen Zero Day Exploits legen aber zumindestens Kontakte zur Cybercrime-Szene nahe.

Besonders interessant ist auch die Tatsache, dass der Urheber von Stuxnet einen Mechanismus geschaffen hat, der die Infektion bestimmter Systeme durch ein 'Hintertürchen' verhindert. Es wäre hochinteressant zu wissen, wo dieses schon lange Zeit im Umlauf ist. (Weitere Informationen, wie Sie dieses Hintertürchen zu Ihrem Schutz vor Stuxnet nutzen können erhalten Sie auf Anfrage bei uns.)

Was die vermeintlich gestohlenen Zertifikate betrifft, mit denen die Dateien von Stuxnet signiert sind, wurden beide betroffenen Zertifikate von der US-Firma VeriSign ausgegeben. Statt dem Diebstahl der Zertifikate könnte man -wenigstens theoretisch- auch die Ausgabestelle dazu bringen, Kopien der ausgestellten Schlüssel herauszugeben ('persuade'/überreden, 'compel'/zwingen). VeriSign verdient neben den Zertifikatsdiensten hauptsächlich an Überwachungsdiensten für Behörden nach dem Communications Assistance for Law Enforcement Act (CALEA) , die von vielen Telekommunikationsanbietern an das Unternehmen ausgelagert wurden. Man sagt dem Unternehmen auch deshalb sehr enge Kontakte zur amerikanischen Regierung nach.

Stuxnet-Epidemie in China

Inzwischen ist auch China unter den Opfern von Stuxnet, das einige wohl ebenfalls im Kreise der verdächtigen Urheber des Wurms sehen oder sahen. Chinesischen Medienberichten zufolge seien im Land Millionen von Rechnern und nahezu 1000 Industrieanlagen befallen, berichtete Heise Online. Laut der South China Morning Post wolle die Regierung eine landesweite Untersuchung von Anlagen mit Siemens-Software durchführen und weitere Aufträge an Siemens prüfen.

Belastbare Zahlen zu den Infektionen in China liegen jedoch nicht vor. Jedenfalls dürfte die von SIEMENS immer wieder genannte Zahl von 15 Infektionen fernab der praktischen Realität liegen. Bei genauerem Hinsehen zeigt sich weiterhin, dass es sich hierbei nur um die Anzahl der bei SIEMENS gemeldeten Infektionen handelt, die auch niemand tatsächlich nachvollziehen kann.

Fazit

Viele Spekulationen über die Urheberschaft von Stuxnet wurden angestellt, einige davon sind sicher falsch, gänzlich unbelegt oder rein in die Irre führend, es verbleiben jedoch mehrere gleichermaßen tragfähige Theorien. Dementsprechend läßt sich im Augenblick weder der Urheber des Angriffs, noch ein definitives Ziel mit sehr hoher Wahrscheinlichkeit festmachen.

Lediglich eines ist sicher: sowohl Betreiber kritischer Infrastrukturen als auch Automatisierungshersteller müssen dringend handeln und solche Risiken nachhaltig in den Griff bekommen. Lösungen existieren, der Handlungsbedarf wurde praktisch aufgezeigt. Einfach nur Abwarten ist womöglich die schlechteste aller möglichen Strategien.

UPDATE 21.10.2010:The Registerberichtete unter Bezug auf iranische Quellen , eine als 'nuclear spies' bezeichnete Personengruppe wäre im Iran verhaftet worden, die jedoch lt. Angaben des iranischen Geheimdienstministers Heidar Moslehi in keinerlei Verbindung mit Stuxnet stünden.

UPDATE 16.11.2010: Laut Informationen von Symantec scheint es sich bei der von Stuxnet gesuchten besonderen Konfiguration um 6ES7-315-2 Steurungen zu handeln, die über CP 342-5 Profibus Kommunikationsmodule und Frequenzumrichter der Typen KFC750V3 (Profibus Geräte-ID: 7050h, Hersteller: Fararo Paya - Teheran, Iran) und Vacon NX (Profibus Geräte-ID: 9500h, Hersteller: Vacon AG - Vaasa, Finnland) mindestens 33 Wechselstrommotoren ansteuern.

Diese Frequenzumrichter unterlägen lt. Symantec der Exportkontrolle der Atomenergiebehörde, da sie u.a. zur Ansteuerung von in der Uran-Anreicherung verwendeten kaskadierte Gaszentrifugen verwendet werden könnten. Die Minimalzahl und die hohe Drehzahl der Motoren (807-1210 Hz bzw. 48420-72600 U/min), die Stuxnet sucht und die Art und Weise, wie diese manipuliert werden, könnte ebenso darauf hindeuten. Daneben gibt es im Bereich der Ultrazentrifugation noch Anwendungsgebiete in der Biochemie. Falls ein Leser weitere Einsatzszenarien solcher schnell drehender Motoren in tagelang dauernden Prozessen kennt, bitte ich um Mitteilung .

UPDATE 10.12.2010: Im Gegensatz zu Symantecs Analyse, die anführt weiterer Schadcode für 6ES7-417 Steuerungen sei abgeschaltet oder nicht vollständig schreibt Ralph Langner in seinem Blog, dieser Code könnte dazu dienen, 1000 Megawatt Turbinen des Typs K-1000-60/3000-3 (Hersteller: Power Machines – Moskau, Russland) in Buschehr zu sabotieren, sofern diese nicht über entsprechende Schutzschaltungen verfügten, oder sich gegen eine übergeordnete Schaltung zur Kaskadierung von Gaszentrifugen richten. Zumindest eine Turbine des o.g. Typs scheint in Buschehr zu laufen .

UPDATE 10.12.2010: Bei Anschlägen auf zwei Atomphysiker im Iran sei einer der beiden Physiker getötet worden .

Mehrere Quellen meldeten , Irans Präsident habe mittlerweile bestätigt, dass Stuxnet "begrenzte" Schäden an den Gaszentrifugen in Natanz angerichtet habe, dies aber "nun nicht mehr möglich" sei. Iran ist bezüglich seines Atomprogramms mittlerweile auch an den Verhandlungstisch zurückgekehrt .

Die 'Cablegate ' Veröffentlichungen erweitern die Liste der Staaten, die ein potentielles Interesse an der Beendigung des iranischen Atomprogramms gehabt haben könnten.

UPDATE 20.01.2011: Weitere Nahrung für Spekulationen hier und hier .


Es hat in der Vergangenheit viele Warnungen gegeben, SCADA -Netze besser zu managen, adäquat zu sichern und deren Integrität sicherzustellen, u.a. auch von uns . Mehrfach und seit Jahren weise ich auf die Gefahren hin, bis an höchste Stellen bei SIEMENS. Obwohl den Verantwortlichen eine vollständige Studie zum kompletten LifeCycle-Management der Anlagen vorliegt, die das bisherige Verfahren im Detail mit möglichen Alternativen vergleicht hat SIEMENS diese bis ins Detail durchdachten Empfehlungen leider nicht aufgegriffen, was sich nun im Nachhinein wohl als gravierender Fehler erwiesen hat.

Traditionell herrscht im SCADA-Umfeld geringe Security Awareness, da sich der Mythos vom "Inselnetz" trotz gegenteiliger Erfahrungen und diverser Studien hartnäckig zu halten scheint.

Der beinahe-GAU

Nun ist es gekommen wie es kommen mußte und auch prophezeit war: seit einigen Wochen ist bekannt, dass ein Wurm kursiert, der gezielt die SIEMENS SCADA/Industrial Control Systeme SIMATIC WinCC und PCS7 befällt .

Dieser hat sich u.a. über den sog. "LNK-Bug " (CVE-2010-2568 , Microsoft Security Bulletin MS10-046 ) verbreitet, bei dem es genügt, ein Verzeichnis mit einer speziell manipulierten Verknüpfung zu öffnen(!) um den Exploit auszulösen. Der somit gestartete Schadcode installiert ein Win32.Stuxnet genanntes Rootkit . Findet der Wurm ein SIMATIC System, manipuliert er dieses inklusive dessen Microsoft SQL Server Datenbank und infiziert gezielt alle Projektdateien, um sich auch auf diesem Wege weiter zu verbreiten. Ansonsten infiziert er erreichbare Laufwerke.

Hartcodierte Passwörter und Datenbank-Bugs

Da die Benutzerkonten und Passwörter für die WinCC MSSQL-Server Datenbank hartcodiert d.h. weltweit in allen Anlagen konstant sind (CVE-2010-2772 ), und zudem seit vielen Jahren in SIEMENS-eigenen Foren öffentlich zu lesen waren , ist der Angriff auf die Datenbank besonders leicht. Zumindestens einen dieser Beiträge hat SIEMENS -nach entsprechender "Bedenkzeit"- mittlerweile vom Netz genommen, Belege dafür liegen uns jedoch vor. Zusätzlich haben wir einen weiteren gravierenden Fehler in der Datenbankkonfiguration gefunden, der bis jetzt nach unseren Informationen nicht öffentlich bekannt ist, und eine eigene CVE-Nummer bekommen müßte. Auf unsere Hinweise dazu reagierte SIEMENS bisher jedenfalls nicht mit der Beseitigung der Fehler.

Unzureichendes Update und Fehlinformationen

Das von SIEMENS veröffentlichte SIMATIC Security Update (aktuell: v1.0.0.11 vom 18.08.2010) ist unzureichend, behebt BEIDE Fehler nicht, und verhindert auf älteren Anlagen u.U. noch nichtmal die Weiterverbreitung des Wurms über Projektdateien. Neben der sehr unübersichtlichen Struktur des dazugehörigen Security Advice sind darin auch noch gefährliche Falschinformationen enthalten:

  • "Um eine solche Infektion zu verhindern, wird dringend empfohlen, dass die Anwender nur über Hauptbenutzer-Rechte verfügen. Ein Hauptbenutzer hat nicht die nötigen Rechte, um Code von einem anderen Laufwerk zu starten". (Hervorhebungen durch den Autor)

Wenig Reaktion auf dramatische Probleme, Entdeckung lange später reiner Zufallsfund

Auf diese Hinweise mit dem Zusatz, dass neben diesen drei Sicherheitslücken noch mehr als ein Dutzend weitere vorhanden sind -Sie ahnen es- keine ernsthafte Reaktion.

Durch das von uns seit Jahren angeprangerte fehlende Sicherheits- und Integritätsmanagement wurde der Virusbefall noch nicht einmal von SIEMENS selbst festgestellt, sondern durch Frank Boldewins Zufallsfund bei der Analyse einer Malware, der durch die Presse ging .

Der Wurm soll mindestens seit über einem Jahr (Juni 2009) unbemerkt in mehreren Varianten kursieren und lt. neuesten Informationen sogar SPS -Systeme mit einem Rootkit infizieren und nebenbei auch die 'Conficker'-Sicherheitslücke (MS08-067 ) zur Verbreitung nutzen können.

Da die Reaktion des Herstellers aus meiner Sicht punktuellen Aktionismus statt einer nachhaltigen Problemlösung darstellt, kann ich allen SIEMENS SIMATIC WinCC und PCS7 Nutzern nur dringend empfehlen, Ihre Netze von einer neutralen Instanz auditieren zu lassen und entsprechende Gegenmaßnahmen zu ergreifen.

Security Audit in der Praxis

In von uns durchgeführten Security Audits wurden -auf lediglich mit PCS7 installierten PCs- zwischen 76 und 266 kritische (d.h. von remote ausnutzbare) Sicherheitslücken festgestellt (insgesamt: zwischen 153 und 389).

Für die Auditierung können Sie sich auch vertrauensvoll an uns wenden . Forensic Investigations berät Sie gerne und bietet Ihnen entsprechende Lösungen und Services für Integritäts- und Sicherheitsmanagement , Endpoint Security, Desaster Recovery, Auditierung, Vulnerability Assessment und Patchmanagement – speziell zugeschnitten auf die Anforderungen in SCADA/Industrial Control Systems Netzwerken .

Daneben bieten wir Beratung zu Incident Response Strategien sowie die digitale forensische Sicherung, Analyse und Auswertung solcher Vorfälle an.

Wir verfügen über 25 Jahre Erfahrung im Sicherheitssektor, 10 Jahre Erfahrung beim Softwaremanagement im Anlagenumfeld und über mehr als 30 Jahre Erfahrung im Automatisierungssektor. Wie effizient weltweites Analagenmanagement im konkreten Fall aussehen hätte können, sehen Sie in den folgenden Videos.


Hier mein Bericht vom Workshop "Forensik und Internetkriminalität " des CAST e.V. (Competence Center for Applied Security Technology), der heute am Fraunhofer Institut für Graphische Datenverarbeitung in Darmstadt abgehalten wurde, Forensic Investigations war natürlich dabei.

Prof. Dr. Harald Baier von der Hochschule Darmstadt und Prof. Dr. Felix Freiling von der Universität Mannheim führten durch die Veranstaltung und sorgten und für eine sehr gelöste Atmosphäre. Alles in Allem fand ich die Veranstaltung sehr gelungen, die überwiegende Zahl der Vorträge hatte ein gutes bis sehr gutes Niveau. Die Teller beim Mittagessen waren nicht so optimal sauber gespült, das ist wohl schon fast das Negativste, dass ich anmerken könnte.

Alexander Geschonnek referierte über die forensische Praxis bei der KPMG, insbesondere über Aspekte des Datenschutzes sowie organisatorische und rechtliche Probleme und Risiken, die sich bei der Arbeit ergäben. Hier waren insbesondere die Probleme rund um die informelle Selbstbestimmung und des Schutzes des Persönlichkeitsrechts der Mitarbeiter eines Unternehmens Thema, die bei fehlendem Verbot der privaten Internetnutzung am Arbeitsplatz greift. Auch in unserer Praxis führt dies regelmäßig zu Beweisverwertungsverboten vor Gericht oder wir dürfen erst gar nicht alle vorhandenen Daten in die forensische Akquise und Untersuchung einbeziehen. Dadurch geht ggf. belastendes Material verloren, falls der Mitarbeiter einer Untersuchung nicht zustimmt, was zu Recht Beschuldigte in der Regel nicht tun werden. Ich kann deshalb allen Unternehmen als vorbeugende Maßnahme nur dringend anraten, jegliche private Nutzung der Unternehmens-PCs, insbesondere Nutzung des Internets und Versenden privater E-Mails vertraglich zu untersagen.

Im semi-interessanten Vortrag von Stefan Müller von Symantec Deutschland wurde der "Threat Report 2009 " vorgestellt. Jedoch berichteten andere Referenten und Besucher, dass die Bedrohungslage technologisch weiter fortgeschritten sei, als der Report wiedergäbe. Stefan Müller erläuterte unter anderem, dass die AntiViren-Hersteller dem "Hase & Igel"-Spiel per Pattern-Updates kaum mehr folgen könnten und hier neue, intelligente(re) Techniken zur Erkennung entwickelten, die zumindest in den Consumer-Produkten des Hauses bereits eingesetzt würden. Warum man jedoch die neue Technologie ausgerechnet bei den Consumer-Produkten zuerst einsetze, blieb offen.

Dr. Thorsten Holz von der TU Wien zeigte Teile aus seinen Forschungsarbeiten, in denen er bekannte Botnetze analysierte. Er konnte hier Erkenntnisse über Botnetze, Anzahl der infizierten Rechner und eingesetzte Technologien wie Fast Flux und Double Fast Flux vorstellen. Aus diesen Daten hat er u.a. mittels der bekannten Preise für eBay-Accounts, gestohlene Kreditkartennummern und Identitäten u.ä. mögliche Umsätze der Schattenwirtschaft hochgerechnet. Auch Techniken der modernsten Trojaner aus dem Banking-Bereich stellte er in seinem sehr interessanten und gelungenem Beitrag vor. Phishing -Emails mit der Aufforderung zur TAN -Eingabe auf gefälschten Seiten mit ähnlichen lautenden Adressen dürften inzwischen allgemein bekannt sein. Neueste Banking-Trojaner sind jedoch in der Lage, Transaktionen mittels "Man-in-the-middle" Attacke beim Online-Banking auf den Original-Seiten der Bank so zu manipulieren, dass es selbst dem aufmerksamen Benutzer nicht auffallen kann. Sogar die sonst an dieser Stelle angeratene Überprüfung des Sicherheitszertifikats der Internet-Seite greift hier nicht. Auch Systeme mit Smartcard -Unterstützung (HBCI ) sind für solche Attacken anfällig. Hier bleibt nur der Rat, neben den üblichen Vorkehrungsmaßnahmen wie aktuelle Virenschutzsoftware zu verwenden, Sicherheitsupdates von Internet-Browsern und Betriebssystem zeitnah durchzuführen vor allem die Kontoauszüge regelmäßig zu überprüfen (am Kontoauszugdrucker, NICHT online!) bzw. gar ganz auf Online-Banking zu verzichten. Selbst beim Starten eines Browsers von einem nicht-beschreibaren Medium wie z.B. einer Knoppix-CD gibt es keine vollkommene Sicherheit.

Der Beitrag von Holger Morgenstern zum Thema "Forensik auf Smart-Phones - Möglichkeiten und Probleme", an dem ich eigentlich auch sehr interessiert war, fiel leider aufgrund Erkrankung des Referenten aus. Gute Besserung an dieser Stelle.

Etwas kompensiert wurde dieser Verlust dadruch, das ein Vetreter von Cellebrite , einem Hersteller forensicher Systeme für mobile Geräte, direkt neben mir saß und mir über die neuesten Entwicklungen in diesem Bereich berichtete und mir die Geräte kurz demonstrierte. Danke & Grüße von hier aus Patrick!

Dietmar Breitling von der SEB AG berichtete über IuK-Kriminalität aus Sicht eines Bankers. Durch diesen Beitrag konnte ich erstmals ansatzweise nachvollziehen, welche Gründe hinter der m.E. schneckenlangsamen sicherheitstechnischen IT-Entwicklung im Bankensektor stecken, und warum hier noch Technologien aus der "IT-Steinzeit" wie Magnetstreifen eingesetzt werden, die bekanntermaßen sicherheitstechnisch extrem anfällig sind (mit 10€ Einsatz im Elektronik-Bastlerladen ohne großes Know-How zu knacken). Man will wohl primär die Kunden nicht verunsichern und Schwierigkeiten mit der Bafin vermeiden, gewisse "Streuverluste" durch Betrugsfälle sind offensichtlich einkalkuliert und preisgünstiger als der flächendeckende Einsatz neuer Systeme. Aus betriebswirtschaftlicher Sicht ist Kapital in der Zukunft natürlich billiger als Kapital in der Gegenwart, weshalb sich die Situation ohne regulatorische Auflagen sicher nicht so schnell maßgeblich bessern wird, zudem man ja auch immer bequem argumentieren kann, das alles sei so "branchenüblich". Bleibt der Fairness halber noch anzumerken, das Dietmar Breitling dies in dieser Form und Deutlichkeit nicht oder allenfalls sehr verklausuliert berichtete, dies ist lediglich meine (subjektive) Interpretation.

Herr D. (Name bek.) von einem deutschen Landeskriminalamt brachte äußerst interessante Fakten und die m.E. verlässlichsten Zahlen über die Schattenwirtschaft zutage. Dies ging jedoch derart in die Tiefe der organisatorischen Strukturen und Methoden, dass ich hier nur die dort gegebene Warnung wiederholen möchte: dem LKA lägen Informationen vor, dass die noch nicht geschlossene Sicherheitslücke in Adobe Acrobat 9.2 und Adobe Reader 9.2 bereits von bekannten Botnetzen eingesetzt würde, um weitere Rechner unter Kontrolle der Täter zu bringen. Auch andere Quellen hatten zwischenzeitlich berichtet, das bereits ein Exploit für das Metasploit Framework vorliegt, sodaß von praktischen Angriffen gegen diese Sicherheitslücke auf breiter Front auszugehen war. Ich kann deshalb nur dringend anraten, JavaScript in Adobe Acrobat und Reader auszuschalten , bzw. unter Windows ein Registry-File einzuspielen, dass die betroffene JavaScript-Funktion deaktiviert. Ein offizieller Patch für diese Sicherheitslücke soll lt. Hersteller erst am 12. Janauar 2010 erscheinen. Dies wird den Internetkriminellen sicher ein "frohes Fest" bescheren.

RA Niels Hoffmann (VBB Rechtsanwälte, Düsseldorf ) vertiefte die auch schon von Alexander Geschonnek angeschnittenen Risiken privater forensischer Ermittlungen aus juristischer Sicht sehr praxiskompetent unter dem Thema "Strafbarkeitsrisiken von computerforensischen Dienstleistungsanbietern und Beweisverwertungsprobleme im Zusammenhang mit computerforensischen Datenerhebungen".

Er beklagte u.a., dass die Rechtssprechung in weiten Teilen Interpretationssache und somit, auch aufgrund des technischen Informationsstands der Justiz, eine Art Glücksspiel sei und auch viele Bestimmungen im Strafrecht nicht den praktischen Anforderungen genügen würden. Insbesondere das Urteil des Bundesverfassungsgerichts zum Thema "Dual Use" Software (BVerfG, 2 BvR 2233/07 vom 18.5.2009) sei nicht so glücklich ausgefallen, da auch hier schwammige Begrifflichkeiten wie "Schadprogramme, deren objektiver Zweck in der Begehung von Computerstraftaten liegt" oder "bestimmungsgemäße Wartung und Pflege" vorkämen.

Eine Differenzierung zwischen "Dual Use" Sicherheitsprogrammen und "Malware" ist auch m.E. wenn überhaupt nur in Einzelfällen möglich, da letztendlich auch jede Malware geeignet ist, die Anfälligkeit -oder im Umkehrschluss Sicherheit- von Systemen zu testen, womit sich meist automatisch ein möglicher "Dual Use" ergibt, sei es nur um die Erkennung einer Malware durch AntiViren-Software zu verifizieren. Lediglich das schwer zu belegende Motiv des Einsatzes bliebt als Unterscheidungskriterium übrig, was m.E. auch das Urteil so wiedergibt. Der Verkauf von Software wie Passwort-Crackern bleibt damit aber nach wie vor ein gewisses Risiko, wenn dieser auch an Personen erfolgt "von deren Vertrauenswürdigkeit nicht ausgegangen werden kann". Überspitzt gesehen müßten analog auch Baumärkte angehalten werden, Schaufeln auch nur an "vertrauenswürdige Personen" zu verkaufen, damit möglichst niemand damit erschlagen wird.


Bereits vorletzte Woche berichteten u.a.heise online und The Register mit Bezug auf einen Bericht von Sky News (ACHTUNG: geht Richtung RTL2-Niveau!), der Code von Stuxnet sei in einem Underground-Forum aufgetaucht und werde dort gehandelt.

Man muss hier sehr fein differenzieren, was Dichtung und Wahrheit ist. Der Wurm wird keine nukleare Katastrophe auslösen können. Ebenso unrealistisch ist aber die Betrachtungsweise in einem Anfang November beim CIP Seminar von SIEMENS offiziell veröffentlichtem Papier , das mit lauter schönen grünen Häckchen suggeriert, alles sei in bester Ordnung, und es drohe keinerlei Gefahr mehr. Die Wahrheit liegt wie immer zwischen den Extremen.

Quellcode im Umlauf oder nicht, wo liegt der Unterschied?

Auch wenn der Bericht von Sky News nahezu reißerisch verfasst ist, und die darin enthaltenen Schlussfolgerungen größtenteils falsch sind: ich halte das Auftauchen des Quellcodes für sehr wahrscheinlich, da es mit hoher Wahrscheinlichkeit entsprechende Verbindungen der Stuxnet-Macher mit der Cybercrime-Szene gab oder gibt, und der Quellcode sicher sehr begehrt ist.

Letztendlich macht es aber relativ wenig Unterschied, ob der Quellcode nun aufgetaucht ist oder nicht. Man muss dazu zunächst verstehen, dass

  • Stuxnet modular aufgebaut ist. Die enthaltenen Exploits sind austauschbar und stellen auch lediglich einen Transportweg für den tatsächlich enthaltenen Schadcode dar, der Steuerungen manipulieren kann. Bis jetzt ist dies nicht oder nicht in großem Umfang geschehen, aber wohl nur aus dem Grund, dass es auch gar nicht so beabsichtigt war.
  • es nicht genügt, dass alle aktuellen Virenscanner Stuxnet in seiner jetzigen Form erkennen können, selbst ohne den Quellcode ist es möglich den Wurm zu verändern oder/und mit im Umlauf befindlichen Crimeware-Paketen durch Polymorphismus nicht detektierte Varianten herzustellen
  • der in Stuxnet enthaltene Weg zur Manipulation von Steuerungen generischer Natur ist, und der tatsächliche Angriffscode relativ leicht austauschbar und weniger umfangreich ist

Es macht also lediglich einen Unterschied beim Zeitfenster aus, in dem neue Angriffe erwartet werden können: mit dem Quellcode könnte ein Angreifer wahrscheinlich bereits jetzt schon wieder sein Unwesen treiben.

Neue Transportwege und komplette Übernahme von Systemen - auch jetzt im Moment möglich

Transportwege

Als Transportweg stünden einem modifizierten Stuxnet-Wurm auch im Moment diverse Wege offen, zu denen beispielsweise der seit ca. 6 Wochen bekannte Internet Explorer 0day (CVE-2010-3962 ) gehört, zu dem gar ein öffentlicher Exploit verfügbar ist, oder der von uns entdeckte SIMATIC Code-Execution Bug .

Systemübernahme

Für die anschließende totale Übernahme des Rechners stehen zudem mindestens drei verschiedene Wege zur Verfügung: der nicht behobene Fehler im Task Planer , der Windows UAC-Bypass und die von uns entdeckte WinCC Datenbank-Lücke . Für die ersten beiden Bugs sind öffentliche Exploits verfügbar, letzterer ist auch von drittklassigen Cyber-Kriminellen mit einer Zeile Änderung in Stuxnet ausnutzbar.

Steuerungen generell anfällig

Der Designfehler Das 'Feature', dass es erst ermöglicht, Steuerungen nach dem Schema von Stuxnet zu manipulieren ist nach wie vor vorhanden . Durch dieses Angriffsschema werden sowohl Überwachung als auch Steuerung der Automatisierungssysteme gänzlich unmöglich gemacht.

Stand des SIEMENS Stuxnet-Papiers

  • Die von uns entdeckten Sicherheitslücken mit extrem hohen Risk-Scores (errechnet nach dem CVSS -Standard) werden großzügig verschwiegen und ignoriert, offiziell existieren Sie scheinbar nicht:
  • Sämtliche Fehler zur Privilegieneskalation sind in dem Papier ebenfalls nicht enthalten
  • Immerhin findet der Bug im Druckerwarteschlangendienst schonmal Erwähnung, im Advisory fehlt jeder Hinweis darauf aber weiterhin
  • Der Aspekt der Neukompilierung, Repaketierung, des Polymorphismus oder des Auftetens neuer Varianten fehlt ebenso, der Schluss "zukünftige Infektionen unwahrscheinlich" ist deshalb m.E. so weder zulässig noch richtig
  • Nichts zum Thema der generellen Anfälligkeit der Steuerungen
  • Ralph Langners Kommentar zu dem besagtem Papier: "[go] back to the lab, please "

Risiken missachten – die schlechteste aller Strategien – Aussitzen geht schief

Eine nachhaltige Problemlösung ist weiterhin, nach nun fast viereinhalb Monaten, nicht in Sicht. Offenbar sollen seitens SIEMENS alle Probleme mittels PR-Mechanismen 'weggelächelt' oder ausgesessen werden. Solange einige der großen Kunden derartig geschönter 'Information' Glauben schenken, könnte dieses Konzept auch aufgehen.

Nächste Schritte

Als nächsten Schritt könnten wir das US-CERT kontaktieren, wenn SIEMENS nicht endlich reagiert und die Mängel offiziell bestätigt und beseitigt. In ähnlich gelagerten Fällen haben andere Sicherheitsforscher auch nach Ablauf einer gewissen Frist alle Details öffentlich herausgegeben ("Full Disclosure "), womit jedermann die Sicherheitslücken ausnutzen konnte, wenn die Hersteller anderweitig nicht zur Raison zu bringen waren. Die von der zum HP-Konzern gehörenden Firma TippingPoint geleitete "Zero Day Initiative " tut das beispielsweise automatisch nach 6 Monaten .

Ich kann nur nochmals an SIEMENS appellieren, handeln Sie, vor allem im Interesse Ihrer Kunden. Für den Code-Execution Bug haben wir bereits eine Lösung parat . Wie sagte der SIEMENS-Gründer Werner von Siemens so schön: "Es kommt nicht darauf an, mit dem Kopf durch die Wand zu rennen, sondern mit den Augen die Tür zu finden." Diese Tür steht nach wie vor offen.

Gefährliche Signale

Bitte ändern Sie deshalb DRINGENDST Ihre Strategie im Umgang mit Sicherheitslücken. ES GEHT NICHT, die Entdecker solcher Sicherheitslücken einfach zu ignorieren oder gar noch verteufeln zu wollen. Sicherheitslücken verschwinden nicht von alleine. Am Schwarzmarkt werden wohl 6-stellige Beträge für diese Lücken bezahlt; Sicherheitsforscher brauchen dem gegenüber ein Geschäftsmodell.

Wer sich als Hersteller so verhält und nicht bereit ist, solche Leute zu unterstützen, setzt damit ein ganz gefährliches Signal für die Zukunft: man treibt mit dieser Austrocknungsstrategie talentierte Sicherheitsfachleute vielleicht fast geradezu vorsätzlich in die Hände unseriöser Leute. Das Potential talentierter Leute sollte man als Unternehmen nutzen, ansonsten könnte es sich gegen einen richten, und es kann gewaltig sein. Insbesondere, wenn man selbst ein 'Hack Proof Products' Programm betreibt, das angesichts der Sachlage wie ein schlechter Scherz anmutet.

'Bug Bounty' Programm stellt Glaubwürdigkeit (wieder) her

Installieren Sie ein 'Bug Bounty' Programm, das erhöht die Vielfalt der Kompetenzen der beteiligten Personen und bietet hohe Glaubwürdigkeit in die Sicherheit der Produkte, die ein geschlossenes System niemals leisten kann. Nebenbei senkt es wahrscheinlich auch noch die Kosten. Wenn die eigenen Produkte in puncto Sicherheit halten, was sie versprechen, braucht man zudem nie etwas auszuzahlen.

Aber vielleicht hat man es aber auch einfach nicht nötig, sichere Produkte zu schaffen, insbesondere nachdem der Banken-Status nunmehr auch offiziell ist .



Hier finden Sie aktuelle Themen und Hintergründe rund um Sicherheit, Internet und Recht, das Sachverständigenwesen und die Computer-Forensik.

Mon Di Mi Do Fr Sa So
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31