Industrielle Fertigung
Industrielles Internet der Dinge | Industrielle Materialien | Gerätewartung und Reparatur | Industrielle Programmierung |
home  MfgRobots >> Industrielle Fertigung >  >> Industrial Internet of Things >> Internet der Dinge-Technologie

Arkane, komplexe Programme zur Offenlegung von Sicherheitslücken behindern die Sicherheit

Die meisten Produktschwachstellen werden jetzt nicht vom betroffenen Hersteller entdeckt, sondern von externen Quellen wie externen Forschern, und sie sind überall auf der Karte zu finden.

Sicherheitslücken, die potenzielle Sicherheitslücken in Produkten für das Internet der Dinge (IoT) und für industrielle Steuerungssysteme (ICS) schaffen, nehmen ständig zu.

Laut dem neuesten ICS Risk &Vulnerability Report von Claroty wurden in der ersten Hälfte dieses Jahres mehr als 600 offengelegt. Die meisten haben einen hohen oder kritischen Schweregrad, können einfach und aus der Ferne ausgenutzt werden und machen die betroffene Komponente völlig unbrauchbar. Ein Viertel hat keine Lösung oder kann nur teilweise behoben werden.

Ein Beispiel für das potenzielle Wrack, das durch unbekannte Schwachstellen in der Software-Lieferkette verursacht werden könnte, ist der kürzlich benannte BadAlloc-Cluster in RTOS und unterstützenden Bibliotheken von mehreren Anbietern. Diese können für Denial-of-Service-Angriffe oder Remotecodeausführung ausgenutzt werden.

Klick für Bild in voller Größe

(Quelle:National Institute of Standards and Technology)

Millionen von IoT- und Betriebstechnologie (OT)-Geräten – sowie Verbrauchersystemen wie Autos und medizinischen Geräten – sind potenziell betroffen. Doch OEM- und Asset-Owner-Benutzer wussten nicht, dass diese Mängel existieren, bis Microsoft sie im April offenlegte.

Doch die meisten Produktschwachstellen werden jetzt nicht von den betroffenen Anbietern entdeckt, sondern von externen Quellen wie externen Forschern. Aus diesem Grund gibt es Programme zur Offenlegung von Schwachstellen (VDPs). Wie Bugcrowds ultimativer Leitfaden zur Offenlegung von Schwachstellen 2021 erklärt, wurden VDPs eingerichtet, um „einen Mechanismus zur Identifizierung und Behebung von Schwachstellen bereitzustellen, die außerhalb des typischen Softwareentwicklungszyklus entdeckt wurden“. Sie werden normalerweise von Bundesbehörden, Branchenorganisationen und einigen großen Produktanbietern betrieben.

Keine Konsistenz zwischen den Programmen

Als Reaktion auf eine verbindliche operative Direktive der Cybersecurity and Infrastructure Security Agency (CISA) vom September 2020 veröffentlichen Bundesbehörden ihre Richtlinien zur Offenlegung von Schwachstellen – verwirrenderweise auch durch das Akronym „VDP“ gekennzeichnet. Im Juli kündigte CISA seine VDP-Plattform an. Es wird von Bugcrowd und EnDyna bereitgestellt und wird zivilen Bundesbehörden als zentral verwaltete Site dienen, auf der Sicherheitsforscher und andere Schwachstellen auf Behörden-Websites melden können.


Ron Brash

Die meisten VDPs regeln jedoch Schwachstellen in Produkten, nicht in Prozessen oder Konfigurationen. Leider gibt es sehr wenig Konsistenz zwischen ihnen. „Diese Programme sind überall zu finden:Sogar US-Bundesbehörden machen ihr eigenes Ding“, sagte Ron Brash, Director of Cyber ​​Security Insights bei Verve Industrial Protection, gegenüber EE Times . „Keiner von ihnen ist auf maximale Effizienz ausgelegt.“ Selbst diejenigen mit guten Mechanismen, wie den NIST- und ISO/IEC-Programmen, weisen Unterschiede zwischen diesen Mechanismen auf:was und wie gemeldet wird, Durchsetzung und wie die erforderlichen Änderungen von einer bestimmten Gruppe vorgenommen werden.

Brash bemängelte auch einen Mangel an Transparenz bei der Berichterstattung. Die US-Regierung hat den Code für die COTS-artigen Produkte, die sie im Allgemeinen kauft, nicht entwickelt, sodass Bundesbehörden kein echtes Eigentum haben und als Verkehrspolizisten fungieren müssen, sagte er. „Die Personen, die die ‚Polizeiarbeit‘ übernehmen sollten, haben nicht das Wissen, um die anstehenden Probleme oder ihre Auswirkungen wirklich zu verstehen; kann Schwachstellen aufgrund von Budgets, Genehmigungen, einer unzureichenden EoL-Plattform oder der Unfähigkeit, einen Anbieter zur Bereitstellung eines Fixes zu provozieren, nicht effektiv beheben; und haben nicht die Mittel, Konsequenzen zu ziehen oder Verbesserungen zu erzwingen.“

Auch fehlt es an der Eigentümerschaft für eine bestimmte Beratung und für die Synchronisierung der diesbezüglichen Maßnahmen zwischen staatlichen Programmen und Anbieterportalen. "Es ist alles beste Anstrengung", sagte Brash. „Die großen Anbieter übernehmen oft die Verantwortung, aber ihre verschiedenen Geschäftsbereiche könnten es alle anders machen. Da jedes Produkt mehrere Produkte kombinieren kann, vervielfacht sich die Anzahl der Anbieter noch mehr.“

CVE-Berichtssystem hat Einschränkungen

CISA sponsert die beiden zentralsten US-amerikanischen VDPs:die National Vulnerability Database (NVD), die vom National Institute of Standards and Technology (NIST) gehostet wird, und das etwas ältere Common Vulnerabilities and Exposures (CVE)-Programm, das von MITRE betrieben wird und öffentlich bekannt gibt bekannte Schwachstellen. CISA hostet auch die ICS-CERT-Advisories, die Exploits und Probleme beinhalten.

„Selbst wenn wir den gesamten Offenlegungsprozess und die Forschungsaspekte ignorieren, ist das [CVE-Berichtssystem] geheimnisvoll und komplex“, sagte Brash. „Die meisten Anlagenbesitzer verfügen nicht über das erforderliche Wissen, um OT/ICS-Sicherheitshinweise angemessen zu verstehen oder entsprechend zu handeln. So werden sie durch die schiere Menge an Informationen gelähmt.“ Diese Komplexität wird deutlich, wenn man sich Brashs YouTube-Präsentation ansieht, eine 101, um sie zu entschlüsseln.

Das CVE-System beinhaltet nicht alles:Eine wachsende Zahl von Schwachstellen taucht dort nicht auf. Laut Risk Based Security wurden im Juli 2.158 Schwachstellen veröffentlicht, davon 670 ohne CVE-ID.

„CVEs sind auf Schwachstellen beschränkt, die eine breite Palette von Software betreffen, die viele Unternehmen verwenden können“, sagte der unabhängige Sicherheitsforscher John Jackson, Gründer der ethischen Hackergruppe Sakura Samurai, gegenüber EE Times . „[Aber] eine Schwachstelle könnte spezifisch für die Logik in Software oder auf einem Server sein, der nur einem Unternehmen gehört.“

Bundes-VDPs zielen hauptsächlich auf Bundesbehörden ab, sagte Brash. Für kommerzielle Unternehmen ist wenig verfügbar:Einige Branchen haben ihre eigenen Regulierungsbehörden, wie die North American Electric Reliability Corporation (NERC) für Stromversorger. Obwohl die Richtlinien und Verfahren der Bundesbehörden für die Verwendung in der Privatwirtschaft gespiegelt werden könnten, können sich diese mit jeder Präsidentschaftswahl ändern, betonte er.

„Einige Open-Source-Community-Projekte verwalten die Offenlegung von Sicherheitslücken ziemlich gut“, sagte Brash. „Zum Beispiel werden einige Teile des Linux-Kernels gut verwaltet; andere nicht so sehr, und das berücksichtigt noch nicht einmal das gesamte Linux-Ökosystem. Und im Vergleich zu anderen freien und Open-Source-Softwareprojekten oder sogar verschiedenen proprietären Produkten weisen auch sie sehr unterschiedliche Sicherheitspraktiken auf.“

Melde- und Offenlegungsprobleme

Die mangelnde Konsistenz zwischen den Programmen, insbesondere bei der Berichterstattung, kann Drittforscher in Schwierigkeiten bringen, ganz zu schweigen von den möglichen rechtlichen Problemen, die durch den Computer Fraud and Abuse Act (CFAA) verursacht werden.


John Jackson

„Viele VDPs verlangen von Hackern, dass sie ihre Ergebnisse nicht diskutieren, aber die Programme bezahlen sie nicht oder geben ihnen keinen Anreiz, überhaupt zu hacken“, sagte Jackson. „Außerdem werden sie in der Regel von Nicht-Sicherheitspersonal schlecht oder schlecht verwaltet, was die Zusammenarbeit erschwert. VDPs, die Bugcrowd verwenden, sind ein guter Anfang, da sie Hackern eine effektive Zusammenarbeit ermöglichen und Triager zunächst einen Blick auf die Schwachstelle werfen können, um sie zu bestätigen. Dies mindert jedoch nicht den Bedarf an regelmäßiger Sicherheit.“

In einem Bericht der NTIA Awareness and Adoption Group aus dem Jahr 2016 heißt es:„Die überwiegende Mehrheit der Forscher (92%) engagiert sich im Allgemeinen in irgendeiner Form der koordinierten Offenlegung von Schwachstellen. Die Androhung rechtlicher Schritte wurde von 60 % der Forscher als Grund angeführt, dass sie möglicherweise nicht mit einem Anbieter zusammenarbeiten, um eine Offenlegung vorzunehmen. Nur 15 % der Forscher erwarteten ein Kopfgeld als Gegenleistung für die Offenlegung, aber 70 % erwarteten eine regelmäßige Kommunikation über den Fehler.“

Laut Bugcrowds Ultimate Guide 2021 gaben 87 % der Unternehmen mit eigenem VDP an, eine kritische Sicherheitslücke daraus zu ziehen. Aber während 99 % sagen, dass sie erwägen, ihrem VDP mit einem Bug-Bounty-Programm beizutreten, geben nur 79 % an, dass sie Forscher tatsächlich für "wirksame Ergebnisse" bezahlen.

Da das Problem bei Schwachstellen in eingebetteten IoT-Produkten besonders kompliziert wird, sollte der Offenlegungsprozess standardisiert werden, sagte Brash. Es muss auch „einen Stock geben, um dies durchzusetzen“, sowohl auf der Seite des Asset-Eigentümers als auch auf der Seite der OEM-Produktentwickler. Er stellt sich ein Register für eingebettete IoT-Produkte wie die für Autorückrufe vor. „Ich glaube, es sollte auf dem Teller des Anbieters und Systemintegrators liegen, sicherzustellen, dass ein Asset-Eigentümer zumindest über eine Schwachstelle in seinem Asset informiert wird. Wie bei einem Autorückruf kann der Besitzer dann entscheiden, ob er das Risiko übernimmt, das Problem beheben oder ein anderes Produkt kaufen möchte.“

>> Dieser Artikel wurde ursprünglich auf unserer Schwesterseite EE veröffentlicht Zeiten.


Internet der Dinge-Technologie

  1. Der Weg zur industriellen IoT-Sicherheit
  2. Firmware-Sicherheit neu definieren
  3. Bekämpfung von Sicherheitslücken des industriellen IoT
  4. IoT-Sicherheit – wer ist dafür verantwortlich?
  5. Alles läuft IoT
  6. IoT-Sicherheit – Ein Hindernis für die Bereitstellung?
  7. Nachrüstung der Cybersicherheit
  8. Sicherung des IoT durch Täuschung
  9. Eine ICS-Sicherheitscheckliste
  10. Sicherheitslücke in der IoT-Lieferkette stellt eine Bedrohung für die IIoT-Sicherheit dar