Forensic Investigations / Fi Blog

Fi Blog

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.


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