Frage:
Sollten wir die Sicherheitsprobleme, die wir in unserem Produkt gefunden haben, als CVE veröffentlichen oder können wir diese einfach in wöchentlichen Versionshinweisen aktualisieren?
Filipon
2019-03-13 16:27:19 UTC
view on stackexchange narkive permalink

Wir sind ein Anbieter, der ein Produkt anbietet, das in Unternehmen eingesetzt wird. Wir wissen, dass Unternehmen, die regelmäßig CVE-Scans von Produkten durchführen, einen Teil ihres Schwachstellenmanagementprozesses verwenden. Meine Frage ist, müssen wir einen CVE erstellen, wenn unser eigener Sicherheitsforscher eine Sicherheitslücke in unserem Produkt gefunden hat, oder können wir diese Sicherheitslücke einfach in den wöchentlichen Sicherheitsupdates erhöhen, die wir auf unserer offiziellen Website veröffentlichen?

Es scheint, dass Sie Ihr Produkt verkaufen.Haben Sie eine vernünftige Möglichkeit, die Informationen an alle Ihre Kunden und nur an Ihre Kunden weiterzugeben?(d. h. durch Senden einer E-Mail, anstatt eine Ankündigung auf Ihrer Website zu veröffentlichen).Die Antwort auf diese Frage kann Ihnen helfen, zwischen den folgenden Antworten zu wählen.
Sechs antworten:
Polynomial
2019-03-13 16:33:08 UTC
view on stackexchange narkive permalink

Sie können beides tun, aber ich empfehle, einen CVE zu beantragen, damit Kunden, die Feeds mit Bedrohungsinformationen erhalten, das Problem eher bemerken und einen Patch beschleunigen. Das Zuweisen eines CVE erleichtert auch das Verweisen auf eine bestimmte Sicherheitsanfälligkeit in der allgemeinen Kommunikation, wenn Sie dies später benötigen. Dies ist auch ein Signal an Ihre Kunden, dass Sie die Sicherheitstransparenz ernst nehmen.

CVEs werden von MITRE zugewiesen und verwaltet, und Sie können das CVE-Antragsformular verwenden, um eine Anfrage zu stellen.

Haben Sie Erfahrung aus erster Hand mit der Bewerbung als Verkäufer für ein kommerzielles Produkt für einen Lebenslauf bei der Root-Cna?
@eckes Ich habe den Prozess noch nie selbst durchgeführt, aber ich habe mit und für Anbieter gearbeitet, die CVEs beantragt haben, und soweit ich das beurteilen konnte, war der Prozess nicht anders, als wenn ein Dritter ihn beantragt hätte.
Ja, sollte der gleiche Prozess sein, die Frage ist, wie schnell die Umkehrung war und was passiert, wenn man sie einige Male im Jahr wiederholt
@eckes Oh, die CVE-Zuweisung ist im Allgemeinen ziemlich schnell.Ich habe sie innerhalb von Stunden zuvor zugewiesen bekommen.Die längste Wartezeit, die ich jemals hatte, betrug 6 Tage, aber es gab mildernde Umstände (zwei Personen, die für die Zuweisung von CVEs bei MITRE verantwortlich waren, waren gleichzeitig krank).
Gut zu wissen, hört sich so an, als hätte sich das verbessert!
Ich kann bestätigen, dass die Leute bei MITRE sehr fleißig sind. In meinem Fall haben sie mich sogar über eine Verwechslung mit Kennungen auf einer anderen Site informiert.In Bezug auf die Registrierung von CVEs als Anbieter bin ich sicher, dass sie sich über die Informationen freuen werden, unabhängig von der Quelle.
Luc
2019-03-13 18:10:58 UTC
view on stackexchange narkive permalink

Es wäre hilfreich, das CVE zu veröffentlichen, damit andere wissen, dass ein Update erforderlich ist: Wie Sie sagten, können sie es in Feeds mit Bedrohungsinformationen (oder CVE-Scans) sehen, anstatt das Änderungsprotokoll jedes Updates lesen zu müssen, um zu entscheiden, ob Sie müssen aktualisiert werden.

Als Pentester hilft es uns außerdem sehr bei unserer Arbeit. Wenn wir SAPConnectorDeluxe 4.1.39 finden, überprüfen wir zunächst eine CVE-Datenbank auf Schwachstellen. Selbst wenn die Software proprietär ist und nur von wenigen Unternehmen verwendet wird, ist es für uns hilfreich, die Risiken der Ausführung dieser Software zu kennen, damit wir den Kunden korrekt beraten können.

Außerdem wird angegeben, wie häufig und welche Probleme auftreten: Wenn wir feststellen, dass eine kleine Softwarekomponente im vergangenen Jahr 10 Sicherheitslücken durch Pufferüberlauf aufwies, wissen wir, dass die Entwickler nicht die Zeit haben, Sicherheit in ihren Entwicklungsprozess einzubeziehen. In einem solchen Fall ist es sehr wahrscheinlich, dass mehr Sicherheitslücken gefunden werden oder bereits von böswilligen Parteien gefunden werden.

Das Senden von CVEs ist nicht üblich, wenn die Software nur intern verwendet wird. Wenn wir benutzerdefinierte Software finden, führen wir einige Analysen durch (abhängig davon, wie viel Zeit wir haben) und empfehlen, dass jemand die Sicherheit gründlicher überprüft. Informationen zu internen Produkten würden niemandem außerhalb des Unternehmens helfen, sodass sie nicht in einer zentralen Datenbank wie CVE veröffentlicht werden müssen.

Diese Antwort verbringt viel Zeit damit, einen Grund zu erörtern, warum kein CVE eingereicht werden soll. Das heißt, zu viele können dazu führen, dass Sie schlecht aussehen.Ich denke, die Vorteile des Nachweises Ihres Engagements für die Sicherheit überwiegen, aber diese Antwort wird niemanden davon überzeugen.
In ähnlicher Weise können zu viele CVEs Sie auch zu einem attraktiven Ziel für Hacker machen.Wenn Sie im letzten Jahr 10 Pufferüberlauf-Schwachstellen behoben haben, kann ein Hacker dies als wahrscheinlichen Beweis für einen 11. ansehen und viel mehr Energie auf Sie konzentrieren, als er es sonst tun würde.Selbst wenn Ihre Aktionen ein Engagement für die Sicherheit zeigten und Sie alle Ihre Überlauf-Vulns gepatcht haben, wird die zusätzliche Aufmerksamkeit wahrscheinlich ein nicht damit zusammenhängendes Problem aufdecken.Zu einem bestimmten Zeitpunkt können zu viele CVEs selbst zu einer Sicherheitshaftung werden.
Um die obigen Kommentare zu ergänzen, habe ich das Gefühl, dass CVEs manchmal (kostenlos) als kostenlose Werbung verwendet werden, um den Namen eines ansonsten unbekannten Produkts in Tausenden von Feeds zu finden.
Sjoerd
2019-03-13 17:29:09 UTC
view on stackexchange narkive permalink

Sie müssen kein CVE anfordern, können dies jedoch tun, wenn Sie der Meinung sind, dass es nützlich ist.

Ein CVE ist nur eine zentrale Nummer, die eine Sicherheitsanfälligkeit identifiziert, die bei der Unterstützung hilfreich sein kann Kommunikation über Schwachstellen. CVEs sind besonders hilfreich, wenn mehrere Parteien beteiligt sind. Jeder kann einen CVE in Ihrem Produkt anfordern, aber meiner Meinung nach sieht es besser aus, wenn Sie es selbst tun, bevor es jemand anderes tut.

Kleine Bemerkung: Sie sagen: "Es sieht besser aus, wenn Sie [einen CVE für eine Vuln in Ihrem Produkt anfordern] selbst vor jemand anderem", aber das klingt so, als sollte der Entwickler der Software den CVE immer abrufen, bevor jemand anderes ihn anfordern kann.Für mich wäre das ein Teil des Kredits.Ich würde eher sagen, dass es die Person sein sollte, die es gefunden hat - was in diesem Fall das Unternehmen selbst ist, aber oft (normalerweise?) Nicht.Ich bin mir nicht sicher, wie du es gemeint hast.
Nosajimiki
2019-03-15 01:04:10 UTC
view on stackexchange narkive permalink

Ich denke, die wichtigste Frage ist, ob Ihr Produkt mit einem automatischen Updater ausgestattet ist. Wenn es standardmäßig automatisch aktualisiert wird, kann ein CVE manchmal mehr schaden als nützen, indem es Ihr Produkt für viele Hacker in den Bereich des Bewusstseins versetzt, die sonst möglicherweise nicht wissen, dass Sie überhaupt existieren. Sie können Ihre CVE-Historie einsehen und ein gutes Gefühl für Ihre Sicherheitslage bekommen. Wenn sie viele Korrekturen für "amature" -Fehler sehen, wird Ihr Produkt möglicherweise leicht von Leuten untersucht, die wissen, wie man die dunkeleren Dinge findet, die Sie sonst möglicherweise genug Glück gehabt haben, um sie zu vermeiden.

Auch Produkte, bei denen es unwahrscheinlich ist, dass sie gepatcht werden, selbst wenn Sie ein CVE veröffentlichen, können mehr schaden als nützen. Die meisten IoT-Geräte werden nie gepatcht, daher teilen CVEs Hackern nur mit, welche leicht zu jagen sind.

Wenn für Ihr Produkt normalerweise ein manuelles Update erforderlich ist, das wahrscheinlich erfolgt, wenn Sie ein CVE veröffentlichen, dann sind Sie es sollte es wahrscheinlich tun.

Mike76
2019-03-13 23:38:16 UTC
view on stackexchange narkive permalink

Wenn dies ein wirklich kritisches Problem ist, können Sie das Problem patchen und so lange wie möglich geheim halten.

Dann haben die Kunden einen längeren Zeitraum für die Anwendung von Softwareupdates.

Stellen Sie außerdem sicher, dass Sie so viel binäre Verschleierung wie möglich verwenden, um das "Differential Reverse Engineering" nach der Bereitstellung des Patches zu verhindern.

Wenn Sie es geheim halten, gibt es nicht einen Effekt (den, den Sie erwähnen), sondern zwei Effekte: Ja, Kunden haben mehr Zeit für ein Upgrade, da Bösewichte * möglicherweise * nicht erkennen, dass es eine Sicherheitslücke gibt, aber Kunden werden es auch nicht bemerkenEs gibt ein Problem und könnte lauten: "Meh, wir brauchen diese neuen Funktionen nicht und haben keine Fehler bemerkt. Wir müssen keine Systemadministratorstunden aufwenden, um sie zu aktualisieren."Das heißt, Sie haben mich zum Nachdenken gebracht: Es könnte gut sein, es stattdessen den Kunden privat mitzuteilen, bevor Sie es veröffentlichen (wie dies bei verantwortungsbewusster Offenlegung der Fall ist).
@Luc: Ich glaube nicht, dass Mike vorschlägt, die Existenz eines Patches geheim zu halten.Es sind die Details des Problems, die geheim gehalten werden.Kunden sollten motiviert sein, einen Patch zu installieren, der je nach Schweregrad als "Fixed Remote Code Execution Vuln" aufgeführt ist, ohne den Fehler selbst zu verstehen.
@BenVoigt-CVEs enthalten normalerweise nicht genügend Details, um ein Problem auszunutzen. Nur in einigen Fällen werden sie später aktualisiert, um auf eine Seite mit weiteren Details zu verlinken.Aber tatsächlich hätte Mike das gemeint, ich weiß es nicht.
@Luc: Ich greife nur nach einem zufälligen aktuellen CVE, CVE-2018-7183.Der Titel lautet "Pufferüberlauf in der Decodearr-Funktion in ntpq in ntp 4.2.8p6 bis 4.2.8p10 ermöglicht es Angreifern von Remotestandorten, beliebigen Code auszuführen, indem sie eine ntpq-Abfrage nutzen und eine Antwort mit einem gestalteten Array senden."Das ist nicht genau "genug Detail, um ein Problem auszunutzen", aber es ist sicherlich genug, um Angreifern einen großen Vorsprung zu verschaffen.
Ich schlage vor, in den Versionshinweisen so etwas wie "kritische Fehlerbehebungen, verbesserte Sicherheit" zu schreiben.Die meisten CVEs, die ich gesehen habe, enthalten viel zu viele Details für eine schnelle Offenlegung.
@BenVoigt nur eine Bemerkung, wenn Sie Open-Source-CVEs betrachten, gibt es von Natur aus vollständiger und detaillierter.Kommerzielle Anbieter haben möglicherweise die Richtlinie, keine Details offenzulegen.Oracle zum Beispiel ist notorisch schlecht.
Ralph
2019-03-15 21:03:27 UTC
view on stackexchange narkive permalink

Nur wenige Unternehmen werden Patches sofort anwenden, die meisten werden eine Qualitätskontrolle und -bewertung durchführen, bevor Updates in ihre Systeme aufgenommen werden. Mithilfe der CVE-Definition können sie erkennen, welche Sicherheitslücken in der aktuellen Version der Software bestehen. Anschließend können Sie diese Sicherheitsanfälligkeit bewerten und eine fundierte Auswahl treffen, wann das Update angewendet wird.



ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...