[English]Das Project Zero bei Google ändert seine Richtlinien zur Offenlegung gefundener Sicherheitslücken. Diese sollen ab 2020 binnen 90 Tagen veröffentlicht werden.
Anzeige
Das Project Zero bei Google forscht ja aktiv im Hinblick auf die Aufdeckung von Sicherheitslücken in Softwareprodukten. In einer Mitteilung schreibt Tim Willis, dass das Team viel Zeit damit verbringe, die Richtlinien zur Offenlegung von Schwachstellen und deren Konsequenzen für Benutzer, Anbieter, andere Sicherheitsforscher und die Software-Sicherheitsnormen der größeren Industrie zu diskutieren und zu bewerten.
Aktuell sei man sehr zufrieden damit, wie gut die Offenlegungspolitik in den letzten fünf Jahren funktioniert habe. Es gab Verbesserungen bei der Geschwindigkeit, mit der Anbieter ernsthafte Schwachstellen patchen. Aktuell werden 97,7 % der aufgedeckten Schwachstellen innerhalb der 90-Tage-Offenlegungsrichtlinie behoben.
Interne und externe Diskussionen
Dabei handelt es sich um ein komplexes und oft kontroverses Thema, das sowohl innerhalb als auch außerhalb des Teams häufig diskutiert wird. Das Team erhält oft Rückmeldungen bezüglich unserer aktuellen Richtlinien von Anbietern, mit denen Project Zero eng zusammenarbeitet. Manchmal sind es Dinge, die sie bei uns geändert haben wollen, manchmal ist es die Art und Weise, wie unsere Arbeit ihre Arbeit und die Benutzer positiv beeinflusst hat. Gespräche wie diese helfen dabei die Richtlinien zur Offenlegung zu entwickeln. So hat das Team beispielsweise nach Gesprächen mit verschiedenen Anbietern im Jahr 2015 eine 14-tägige Gnadenfrist zur Offenlegung eingeführt.
Änderungen ab 2020
Vor kurzem hat Project Zero die internen Richtlinien und die Ziele zur Offenlegungspolitik überprüft. Als Ergebnis dieser Überprüfung wurde beschlossen, im Jahr 2020 einige Änderungen an der Richtlinie zur Offenlegung von Schwachstellen vorzunehmen. Für Schwachstellen, die ab dem 1. Januar 2020 gemeldet werden, ändert sich die Offenlegungspolitik:
Anzeige
- Schwachstellen werden standardmäßig volle 90 Tage nach der Entdeckung veröffentlicht, unabhängig davon, wann der Fehler behoben ist.
- Das gilt auch, wenn die Schwachstelle bereits 20 Tage nach der Meldung an die Entwickler behoben ist.
- Die Offenlegungsfrist gilt auch, wenn die Schwachstelle nach den 90 Tagen noch nicht geschlossen wurde.
Wenn es ein gegenseitiges Einverständnis zwischen dem Anbieter und Projekt Zero gibt, können Fehlerberichte vor Ablauf von 90 Tagen der Öffentlichkeit zugänglich gemacht werden. Zum Beispiel möchte ein Hersteller die Öffnung unseres Tracker-Berichts mit seinen Versionsnotizen synchronisieren, um Verwirrung und Fragen der Benutzer zu minimieren.
Aus dem Beitrag von Tim Willis geht auch hervor, dass Google sich die letzten fünf Jahre darauf fokussiert hat, dass die Entwickler entdeckte Schwachstellen binnen 90 Tagen schließen. Aber man hat festgestellt, dass die Qualität der Patches schlechter geworden ist. Mit dem Schwenk auf eine feste 90-Tage-Veröffentlichungsregel will man dazu kommen, dass die Qualität der Sicherheitsupdates steigt und keine Folgefehler eingeführt werden. Auch soll sichergestellt werden, dass die Entwickler die Ursache der Schwachstellen beseitigen und nicht nur einen schnellen Patch liefern, der nicht die Ursachen beseitigt.
Das Team Zero will diese Richtlinie 12 Monate lang ausprobieren und dann überlegen, ob diese beibehalten werden sollen. Weitere Details sind in der Mitteilung von Tim Willis nachzulesen. Ergänzung: Inzwischen gibt es auch einen Beitrag von mir bei heise.
Anzeige
Exchange 2013 ist eins der besch… Programme, die ich kenne. Meinen ersten Versuch startete ich im Sommer 2014. Als ich das mit einem neuen Server anbot, war Exchange 2013 noch gar nicht für Windows 2012 (R2) freigegeben, zu meinem Glück kam noch rechtzeitig vor Übergabe das cumulative update 5 heraus.
Exchange 2013 setzt nicht mehr direkt auf active directory auf (obwohl AD ursprünglich aus dem Exchange 4-Verzeichnisdienst entwickelt wurde!), und die MMC wurde auch aufgegeben. Stattdessen müssen die User aus der AD importiert werden; die in der AD definierten Gruppen sind aber im Exchange nicht mehr sichtbar – diese müssen im exchange control center angelegt werden und erscheinen dann automatisch im AD.
Öffentliche Ordner werden nicht mehr unterstützt, wurden aber nachträglich eingearbeitet. Rechte auf die öffentlichen Ordner können nur noch über die Powershell vergeben werden!
Bei meiner ersten Installation mit CU5 konnte ich noch Adress-Vorlagen erstellen. Dieses funktioniert beim aktuellen CU15 nicht mehr! Eingaben werden einfach nicht mehr angenommen. Die Erstellung einer Adressvorlage über die Powershell (new-EmailAdressPolicy) ist mir nicht mehr gelungen.
Problematisch wird es, wenn die Mailboxen in eine andere Umgebung übernommen werden sollen, z.B. wenn die AD korrupt ist oder der Server „spinnt" oder die Organisation geändert wird. Das soll über die Powershell gehen (aber nur, wenn der Server noch läuft!): New-MailboxExportRequest -Mailbox -filepath "\\server\Freigabe\.pst". Das funktioniert nur unter sehr speziellen Bedingungen, z.B. muss dem angemeldeten Benutzer die passende Rolle zugewiesen werden (New-ManagementRoleAssignment –Role „Mailbox Import Export" –User „" – da hängt´s schon am Domänen-Administrator!) und der spezielle Exchange-User Zugriff auf die Freigabe hat. Leider schlug bei mir der Export fehl (ohne irgendeine Fehlermeldung!). Ein Export auf ein lokales Laufwerk (z.B. externe USB-Platte) ist übrigens nicht zugelassen.
In meinem Fall funktionierte der empfohlene Weg nicht. Ich war gezwungen, aus dem alten Outlook eine .pst-Datei zu exportieren. Nachdem wir das für alle User erledigt hatten und die PCs in eine neue Domäne übernommen hatten, merkten wir viel zu spät, dass ältere e-Mails fehlten. Es wird nämlich nur der Cache exportiert; selten benötigte e-Mails vermisst man zunächst nicht.
Bald stellte sich das nächste Problem heraus: die ominöse 2 GB-Grenze. Obwohl das alte System diese Begrenzung nicht mehr hatte und auf dem neuen Server alle Postfächer „unlimited" sind, können einige User keine e-Mails mehr senden und empfangen. Im Outlook steht bei diesem Exchange-Konto diese Begrenzung. Möglicherweise wurde mit dem Import der .pst-Dateien die Begrenzung gesetzt und lässt sich leider nicht mehr aufheben!?
Nun versuchte ich, über IMAP an die alten e-Mails heranzukommen. Aber dummerweise ist Exchange zu IMAP nicht völlig kompatibel, die User hatten ihren Postfächern teilweise nichtkompatible Namen gegeben (z.B. / im Namen). Ich muss also einen PC (gleich virtuell) in der alten Domäne einrichten und per Outlook mit großzügigem Cache für alle User wieder .pst-Dateien exportieren. Das ist bei einer kleineren Anzahl von Usern allemal schneller als die ewige Probiererei (ich habe schon Stunden vertrödelt mit dem Versuch, aus dem alten Exchange 2010 die .pst-Dateien herauszuholen!).
Es wird immer verrückter: Outlook 2013 zeigt keine e-Mails eines IMAP-Kontos an, die älter als ein Jahr sind!
und was hat das nun mit Googles Project Zero zu tun?
Denke, der Kommentar ist unter den falschen Artikel geraten – er wäre besser unter Diskussion aufgehoben gewesen.
usb4.0 protokoll-rollout -> nächste runde!..
eeerster!.. wer merkt denn "noch" was?!
lg!