News Sicherheitslücken: Kernel-Entwickler empfiehlt Intel SMT zu deaktivieren

[Laphonso]

Mein AG zählt zur Kritischen Infrastruktur in DE (Siehe https://www.kritis.bund.de/SubSites/Kritis/DE/Home/home_node.html)
Bei uns wurden die üblichen Patches von VMware & Co. eingespielt, das wars. Die gesamte Infrastruktur läuft mit Intel CPUs, die kriegt man nicht alle einfach so ersetzt. Wird bei den anderen auch nicht großartig anders sein.

Wie laufen denn bei Euch die Audits ab ?

 

[AYAlf]

danke fürs beleidigen....

einfach Fehler 80 vermeiden und gescheite Software zur Sicherheit verwenden

Jo ist doch halb so wild. Wer die Tür abschließt, der ist einbruchssicher ... Nö, ist nicht so.
Scheint doch keine Beleidigung zu sein ^^

 

[Laphonso]

Jo ist doch halb so wild. Wer die Tür abschließt, der Einbruchssicher ... Nö, ist nicht so.
Scheint doch keine Beleidigung zu sein ^^

Ich glaube es ging eher darum, dass Deine "Empfehlung", keine Intel Prozessoren zu kaufen in diesem Kontext, komplett absurd ist. Weil sie eher zeigt, dass Du so gar nicht die Problemlage und die Szenarien verstanden hast.
Übrig bleibt dann nur Dein Anti Intel Fußtritt und Deine Abwertung der Gruppe, die Du ausgemacht hast, warum auch immer.

 

[DarkerThanBlack]

Ähm nein.
Paypal gibt dir zwar bescheid wenn dein Konto gehackt wurde aber das ist normalerweise (ohne den Kontext zu kennen) noch kein Schuldeingeständnis, dass das Problem auf ihrer Seite besteht.
Normalerweise stellen die nur fest, dass irgendwer aus z.B. Asien versucht hat etwas für viel Geld auf eine fremde Adresse zu bestellen und machen das Konto dann erstmal dich. Gehackt heist erstmal nur, dass irgendein Fremder Zugriff auf dein Konto hatte.

Dicht gemacht haben sie da gar nichts! Es wurden nur meine Daten gestohlen. Sprich, eindeutig ein Problem von PayPal, so wie man es überall bei anderen Firmen lesen kann. Einen finanzeillen Schaden hatte ich nicht, aber musste trotzdem alle Daten ändern und habe selber mein PayPal-Konto gelöscht.

Eine tatsächliche Sicherheitslücke bei Paypal würde viel größere Wellen schlagen und wäre vermutlich auf allen Titelseiten stehen, da der Dienst riesig weit verbreitet ist. Eine funktionierende Sicherheitslücke bei Paypal dürfte auf dem Schwarzmarkt viele Millionen wert sein.
Sofern es also bei dir keine Millionen zu holen gab geht die Wahrscheinlichkeit, dass Paypal selbst gehackt wurde komplett gegen 0.

Kommt immer drauf an, wie so etwas kommuniziert wird. Was glaubst du was passieren würde, wenn PayPal tatsächlich Millionen Kundendaten verlieren würde? Dann könnten sie ihren Laden dicht machen. Vermutlich beschränkte sich dieser Hackingversuch nur auf wenige Kundendaten oder es wurden nur wenige Daten gestohlen bis PayPal eingegriffen hat und ich war eben der Glückliche, der zu den wenigen gehört hat.
Deshalb würde ich aber nicht gleich zur Presse gehen und verkünden PayPal sei nicht mehr sicher, sondern einfach nur den Dienst nicht mehr nutzen.

 

[gesperrter_User]

Hatte eigentlich erwartet das man in den Rechenzentren so langsam aber sicher von Intel weg geht, eben weil die Sicherheit dort wichtig ist.

Ich kenne es nur so: Der Betreiber wechselt nur wenn es keine Ersatzteile mehr gibt, er diverse Förderungen vom Staat (zb. Energieeinsparung) bekommt oder er die komplette Software umstellt. Ansonst vermeidet er jeglichen umbau am Lebenden System.

Mein AG zählt zur Kritischen Infrastruktur in DE

In AT genau das gleiche wie bei dir. Mobility Sparte: Staat, Militär und externe Berater sind der Meinung, dass Spectre und Meltdown keine Gefahr sind.Sind wir uns mal ehrlich, Interessant ist es höchstens für Anlagen die offen im Internet betrieben werden, unautorisierte Programme installiert werden können oder unbekannte Fremdfirmenmitarbeiter auf diesen arbeiten, aber da hat man ohnehin andere Probleme und sollte mal sein Sicherheitskonzept überdenken.

Das bei einer Einrichtung, die vom BMSI als kritisch eingestuft wird, Performance über Sicherheit gestellt wird geht doch auf keine Kuhaut.

Wird es nicht. Hier wird mit anderen Sicherheitsmaßnahmen gearbeitet. Türkontrollen, Videoanlagen, kein Arbeiten ohne Kunde, Terrorprüfung der MA durch BMI, und und und. Da läuft so einiges mehr im Hintergrund als du dir vorstellen kannst.

 

[textract]

Hat denn jemand real in Unternehmen oder Behörden erlebt, dass SMT aus Sicherheitsgründen deaktiviert wird?

Spectre und Meltdown waren damals bei uns kurz mal Thema, dann hieß es, dass Patches kommen und es hat niemanden mehr interessiert.

Mich würden insbesondere Risikoumgebungen interessieren, also z.B. Virtualisierung für verschiedenste Kunden auf der selben Hardware.

Ja, ist bei einem langjährigen unserer Kunden, bei dem ich im IBM Power Systems Bereich im Einsatz war passiert.
Hier wurden auf biegen und brechen alle möglichen Systeme, nicht nur x86, gegen Spectre und Meltdown gepatcht. Voraussetzung war natürlich, dass die Maschinen noch leistungsfähig genug waren ihren Workload abzuarbeiten, weshalb gezielt einzelne Systeme ausgelassen wurde.

Effektiv war das ganze eher eine gewinnbringende Situation für die Hardwarehersteller, denn damals gab es zu Intel im x86 Umfeld keine Alternative und für POWER schon sowieso nicht. Hier wurden viele neue Maschinen angeschafft, das ging in den mittleren dreistelligen Bereich.

 

[gaelic]

Das ist auch eher eine News die in die Richtung schlägt dass sich große Server-Anbieter wohl noch eher für AMD entscheiden werden (müssen), weil sie für andere verantwortlich sind.

Wo genau liest du das?

 

[dammit_horst]

You won't get 🔥 for buying Intel?

 

[Ned Flanders]

Hier wird mit anderen Sicherheitsmaßnahmen gearbeitet. Türkontrollen, Videoanlagen, kein Arbeiten ohne Kunde, Terrorprüfung der MA durch BMI, und und und.

Ich hab da trotzdem kein Verständnis für. Was ist denn wenn der MA trotz Backgroundcheck Daten aus VMs abgreifen will? Die NSA hat mit an Sicherheit grenzender Wahrscheinlichkeit E. Snowden auch gecheckt und eine Freigabe erteilt.

Wenn man nicht konsequent ist, kann man es auch lassen. Und nur weil man selbst das Risiko für beherrschbar hält, ist es das noch lange nicht. Dafür gibts ja nun wirklich genug Beispiele.

Wenn man trotz der Meinung von vielen Experten (siehe Artikel) meint man muss wegen 20% CPU Performance ein Risiko eingehen, anstatt 20% mehr CPUs zu beschaffen dann ist man imho selbst ein Risiko bei kritischer Infrastruktur.

 

[Joshinator]

Der Betreiber wechselt nur wenn es keine Ersatzteile mehr gibt, er diverse Förderungen vom Staat (zb. Energieeinsparung) bekommt oder er die komplette Software umstellt. Ansonst vermeidet er jeglichen umbau am Lebenden System.

Klar gilt irgendwo "Never change a running system", aber das laufende System hat nun mal Sicherheitslücken die man im VM-Bereich absolut nicht hinnehmen sollte.

Wenn ich irgendwo in einem Zentrum einen VServer für meine Firma hoste möchte ich als zahlender Kunde nicht mit dem Gedanken leben "kann gut sein das jemand Teile der Daten mit abfangen kann".
Auch als Hoster sollte man merken das Handlungsbedarf entsteht, weil bei so tiefgreifenden Designproblemen seiten Intel Patch nach Patch kommen wird, und jedes mal geht mir Geld verloren weil ich weniger Power anbieten kann.

Aber eventuell denke ich auch zu viel nach, nicht grade kleine Firmen haben ja offensichtlich auch kein Problem damit massenhaft Userdaten öffentlich zugänglich zu machen.

 

[fdsonne]

Bis zu 50% Leistungseinbußen durch Softwarelösung ist echt bitter, dafür dass SMT im Schnitt (ist natürlich von Anwendung zu Anwendung unterschiedlich) 20% mehr bringt.

SMT bringt dir nicht 20% mehr - SMT bringt dir je nach Anwendungsfall so viel mehr, dass es zwischen läuft und läuft nicht unterscheiden kann. Gerade in Sachen Virtualisierung kann der zweite Thread Gold wert sein. Denn die CPU Last ist eh idR kein Thema, sondern die meisten Hosts werden wohl eher Probleme bei der Threadzuweisung haben, weil zu viele vCPUs quasi gleichzeitig versuchen ein Zeitfenster für ihre Berechnungen zu bekommen. Bist du nicht in der Lage, physisch genug Threads bereit zu stellen heist das real, dass die Wartezeit steigt. Das System wird langsam und das um weit weit weit mehr wie 20%

Ich hatte hier schon Fälle, wo ungünstige Zuweisung dafür sorgte, dass DNS Anfragen (weil UDP) ins leere liefen, da der DNS Server nicht genug Rechenzeit bekommen hat bzw. permanent warten musste auf ein passendes Zeitfenster. Im Resultat funktioniert dann effektiv gar nix mehr. Hier hilft dir SMT massivst bzw. das ausschalten kostet massiv.

Airlines kaufen ja auch nicht nur Flugzeuge eines Herstellers, die wissen schon warum. Nur bei den ach so logisch denkenden ITlern scheint das noch nicht angekommen zu sein.

Der Aussage nach bist du offenbar kein ITler... Da steckt mehr Logik drin als der Außenstehende sich vorstellen kann. Das Ding ist nur, wenn ich dir jetzt hier erkläre warum und wieso eine inhomogene Infrastruktur nicht wirklich der zielführendere Weg ist - wirst du es glauben? Doch sicher nicht... Wer sich hinstellt und über andere urteilt ohne offenbar mit dem Thema was zu tun zu haben wird auch die Argumente (in keine der möglichen Richtungen) nicht als solche Akzeptieren. Von daher...

Also ich lese immer wieder, wie Firmen gehackt und prekäre Daten gestohlen werden. Ich vermute mal, dies sind alles Server von Intel, welche einfach nicht up-to-date waren?

Streiche Intel und du erschlägst mit der Aussage so ziemlich nahezu alle Security Themen, die so durch die Medien gehen.
Im Endeffekt ist ein Security Incident hier nichts anderes als ein Vorfall, bei dem ein Dritter aufgrund des Einsatzes einer unsicheren Lösung Zugriff erlangt/erlangen kann. Häufig im Resultat aufgrund von alten Systemständen. Da brauch es nicht Intel für - deren "Lösung" funktioniert nachweislich nicht, ein Fix in Hardware benötigt Zeit. Andere Lösungen, gerade Softwareseitig funktionieren auch nicht.

Das eigentlich schlimme ist nur, es gibt zwei Seiten der Medaille. Sogenannte Zero Day Exploits sind die Problemfälle, wo der Angreifer das Wissen darüber hat, in ein System eindringen zu können, weil es ein Sicherheitsproblem gibt, was der Hersteller/Anwender/Anbieter aber gar nicht kennt. Das heist, selbst wenn alle jetzt ab sofort nur noch AMD nutzen würden -> wer weis was da alles geht oder offen steht? Das AMD auch dort kein unbeschriebenes Blatt ist, zeigen die nicht all zu alten Meldungen zum PSP. Die kochen ALLE mit dem selben Wasser. Es ist also ziemlich unsinnig, da einseitig zu argumentieren, weil das keineswegs das Problem löst. Eher im Gegenteil. Sich in einer Art Sicherheit zu wiegen, nur weil es bekannte Vorfälle bei der Gegenpartei gibt, ist so ziemlich das dümmste was man machen kann

Wir betreuen ca. 300 ESX Hosts und haben HT ausnahmslos auf allen Hosts deaktiviert, bisher hat sich kein Kunde über Performanceeinbrüche beschwert oder etwas davon gemerkt.

Ja wie soll er das auch merken? Der Kunde merkt nicht ob ihr SMT aktiv habt oder nicht. Er merkt lediglich, wenn die Hosts nicht mehr in der Lage sind, entsprechende Ressourcen zuzuteilen.
Beobachte mal den CoStop Counter auf euren Hosts. Hast du dort strich 0ms, dann ist der Host in der Lage, ausnahmslos Ressourcen ohne Verzögerung zuzuteilen. -> best case. Um so höher dieser Wert, desto mehr Probleme hat der Host, den VMs entsprechende Zeitfenster einzuräumen. Das geht bis zu mehreren tausend Millisekunden Wartezeit, das merkt man als Nutzer wirklich stark, weil die Reaktionsgeschwindigkeit des Systems stark nach lässt.
Die CPU Last (was in den Foren immer gern angeführt wird) ist meist gar kein Thema... Bei mir liegt diese irgendwo im Bereich 15-35% oder sowas im Dreh. Man braucht da keine x-Cores mehr, damit es schneller wird (denn das wirds nicht, weil die Last gar nicht da ist), sondern man braucht ausreichend viele Threads um Hostseitig die Ressourcen zuteilen zu können. Möglichst ohne Wartezeit!

Hmm heißt das jetzt, in der betrieblichen Virtualisierungsumgebung soll ich jetzt die hälfte alle vcpus abschalten, ja ne ist klar. Das kann nicht die Lösung sein.

Nein, das heist, du sollst Hirn einschalten und eine Risikoanalyse tätigen, um zu prüfen ob was notwendig ist und was nicht.
Es gibt auch andere Mittel und Wege dem Thema quasi aus dem Weg zu gehen. Bspw. sind ESXi Hosts in der Lage bei aktiven MDS Mitigations Security Kontexte zu gruppieren. Das heist, wenn du möchtest, dass der Terminal Server, wo Dritte potentiell Code ausführen können nicht zusammen auf dem selben Core (per SMT) laufen, wie dein SQL Server, dann wäre das die weit sinnigere Option als SMT hart auszuschalten.
VMware bspw. empfiehlt nach wie vor SMT aktiv zu lassen...

 

[Ned Flanders]

Sind vermutlich aber alles AMD Liebhaber

Klar, Greg Kroah-Hartman, Linus Torvalds, ChromeOS Entwicklerteam, OpenBSD Entwicklerteam.... alles Hardcore AMD Fanbois!

Man kann es sich auch einfach machen!

 

[der Unzensierte]

Da langen dann aber die bis zu 315€ Cashback von Asus nicht mehr. Was für ein Desaster für Intel. Aber hey, Hauptsache der Balken ist der längste.

 

[textract]

Die da wären?

Soll doch mal einer von diesen "Klugscheißern" mal offen legen welche Risikos durch SMT entstehen die so gravierend sind so dass...
Sollen sie doch mal Praxistaugliche Schadsoftware präsentieren die Schaden verursacht.
Aber halt, die gibt es ja nicht.

Klar gibt es die. Wie man Spectre und Meltdown ausnutzt hat doch damals das Hackerkollektiv Pythonsweetness gezeigt. Einfach mal maulen, ohne Strahl zu haben was man hier von sich gibt?
Meinst du jeder Exploit gelangt unmittelbar an die Öffentlichkeit?
Laut StGB § 202 c ist schon das reine Sprechen darüber verboten, warum meinst du findet Kommunikation darüber lediglich auf dem Schwarzmarkt und sonstigen Darknet Foren statt?

Bis heute gibt es nicht einen Vorfall bei dem durch die Lücken wie Spectre/Meltdown und Co. irgendwo Schaden entstanden ist.
Alles so hoch theoretische "Sicherheitslücken" so dass nie Schadsoftware die praxistauglich hat ausnutzen können.

Schaden ist dadurch definiert, dass wirtschaftlicher Schaden entsteht und ich sags mal so: Wenn die Zertifizierungsstellen Wind bekommen, dass man Maschinen betreibt und sie bewusst nicht sichert, verliert man seine Zulassung.
Das ist vor allem relevant, wenn seine Systeme FRC, für die USA FDA, oder GxP validiert sein müssen, um mal drei geläufige Beispiele zu nennen.

 

[.Sentinel.]

Das Thema hatten wir schon bis zum Erbrechen:

Es reicht in dem Fall, wenn zwei VMs auf dem selben Kern laufen und schon könnte eine die Daten der anderen auslesen. Problem nur dabei: Diese Lücken sind eher Staubsauger als Pinzette.

Antwort (nur mal ein par Punkte, die man bedenken sollte)

1.Du musst wissen, auf welchem physischen Host die Maschine liegt, die Du angreifen willst.
Dazu meine Frage- Wie erhältst Du die Information z.B. in einem Rechenzentrum?

2.Du musst wissen, ob/welche VM auf dem physischen Host parallel läuft, die nicht "passiv" funktioniert (wie z.B. SQL, LAMP, Exchange etc.).

3.Du musst eine parallel laufende VM infiltrieren. Dabei stellt sich erstmal Frage #2, dann die Frage, ob Du mit Deinem Trojaner/Virus durch die Firewall kommst und dann, ob das OS überhaupt anfällig für das von Dir präferierte Transportmittel ist, da die Maschine für viele Attacken auf entsprechenden Ports lauschen muss bzw. entsprechende Applikationen in anfälliger Versionsnummer nach außen "offen" gestellt sein müssen.

4.Wie Du schon sagst, müssen die Daten KONSISTENT zufälligerweise gerade über den gleichen Cachebereich eines Cores gehen.

5. Brauchst Du den Einstiegspunkt/Header wonach Du vermutest, dass die von Dir gesuchte Information abgelegt sein könnte. Wonach suchst Du überhaupt?
Dazu braucht es eine aufwendige Analyse ähnlich der Datenrekonstruktion auf einer Festplatte, wenn die FAT/MFT fehlt und über die Anwendungen die vom Unternehmen benutzt werden, die relevante Daten enthalten könnten. Sonst schneidest Du nämlich grundsätzlich nur Müll mit.

6.Dann "nur" noch an der Verhaltensüberwachung und den zig no- execution Policies vorbei und schon ist das System infiziert. Wirklich?

7.In den VMs muss die Kernisolation ausgeschalten sein, so dass auch wirklich alle VMs Queerbeet mit allen VCPUs kommunizieren dürfen.

Nehmen wir an, Du kriegst wider Erwarten nun Deinen Exploit auf einem Parallelsystem lauffähig. Dann stellt sich Dir die nächste Hürde in den Weg.

Auf VMs haben CPU- Caches die unangenehme Eigenschaft laufend ihren Inhalt zu wechseln. Wie Du bereits gelesen haben dürftest, ist aber genau das Gift für die verfügbaren Exploits.
Und je fragmentierter und in der Frequenz wechselhafter der Cache- Inhalt ist, ums schwerer lassen sich konsistente Informationen daraus extrahieren.
Je genauer aber Dein Algorithmus zur Analyse der Konsistenz und der Header/Einstiegspunkte und vor allem des Timings z.B. einers ausgelösten Zwangswechsels der VCPU ist (damit Du auf den CPU Kern kommst, dessen Cache Du auslesen willst) ist, umso höher steigt aber auch die CPU bzw. I/O Last.

Möööp- Verhaltensüberwachung meldet sich wieder bzw. das Monitoring schlägt an.

Machst Dus so unauffällig, dass die Laststeigerung auf dem Server unter dem Radar bleibt, gleicht es einem Lotto 6 er mit 5 Zusatzzahlen, überhaupt auf relevante und KONSISTENTE Informationen hoffen zu können.

Das sind jetzt mal nur ein par der Gesichtspunkte, die man berücksichtigen sollte, wenn man von diesen Schwachstellen und deren "Gefahr" spricht.

Die Schwachstellen sind da, sie sind unangenehm. Risikoanalytisch sind sie im Vergleich zu Diensten, die nach Außen im Internet stehen zu vernachlässigen, da man zur Ausnutzung ein Virenverseuchtes System braucht.

Phoronix gibt in akutelleren Tests an, dass die Intel CPUs bei Aktivierung aller Mitigations im Benchmarkschnitt 1,8% zum AMD Pendant verlieren.
Es spricht also auch nichts mehr dagegen, dort "volle Pulle" zu fahren, was die Sicherheitspatches anbelangt.

Da nach "Proof of concept"s gefragt wurde:
https://github.com/crozone/SpectrePoC
https://github.com/IAIK/meltdown

Kann jeder der sich ein wenig auskennt prüfen, wie gefährlich das ist.

LG
Zero

 

[cansys]

Jop hier, gerade im VMware Umfeld hat und das über 30% Prozent Performance Verlust bedeutet, bin mir sogar sicher das die Zahl höher ist und was die Desktops betrifft, hallo Ryzen, byby Intel, Notebooks sind halt im 13" Bereich noch Mangelware, hoffe hier auf Besserung in 2020/21 aber auch dort SMT deaktiviert, schlägt sich durch auf die Leistung bei den meisten...

30 % klingen aber noch sehr "moderat". Bei mir habe ich in Hyper-V ein Verlust von um die 45 - 50 % festgestellt. Das variiert immer je nach Nutzungsintensität. Die Kunden jammern über Intel, wollen aber partout nicht auf AMD wechseln. Sie hätten da "was gehört" oder in der Vergangenheit "schlechte Erfahrung" gemacht. Gut, wer leiden will, soll leiden.

 

[Mr.Baba]

erst demletzt gelesen, dass beim 9900k schon viel in hardware gefixt sei.
und bei den 10000-ern sollte es ja dann noch mehr so sein.

 

[Nizakh]

@cansys Aus Interesse -> Welche Intel Technik kommt bei dir zum Einsatz? Kann mir durchaus vorstellen das es bei älteren Intel Systemen (Haswell und davor) durchaus zu teilweise nicht unerheblichen Leistungsverlusten kommt. Bei aktuellen Intel Systemen sollte es aber nicht so gravierend sein.

erst demletzt gelesen, dass beim 9900k schon viel in hardware gefixt sei.

Hast du dazu eine Quelle? Meines Wissens nach sind die Core i 9000er von Werk aus mit einigen Micro Code Updates versehen, welche das System gegen einige der Lücken härten. Aber einen Hardwarefix gibt es bei denen noch nicht.
Cascade Lake wird aber mit Hardware Fix kommen.

 

[Snowi]

Also ich lese immer wieder, wie Firmen gehackt und prekäre Daten gestohlen werden. Ich vermute mal, dies sind alles Server von Intel, welche einfach nicht up-to-date waren?

Mein Paypal-Konto wurde auch gehackt und ich musste deswegen meine Kontodaten sowie Imail-Adresse und Telefonnummer ändern...

Bei PayPal bin ich natürlich nicht mehr. Bin mal gespannt, bis der nächste Server gehackt wurde, worin ebenfalls meine Daten liegen.

Die meisten "Hacks" von denen man hört kommen nicht durch sowas zustande. Sowas passiert weil geschlampt wird.

Beispiel Adobe letzte Woche: Ein offenes ElasticSearch. Da hat einfach jemand vergessen die Firewall entsprechend zu konfigurieren, oder sehr viel wahrscheinlicher: Da hat jemand vergessen, den Kollegen im Netzwerkteam zu sagen, dass sie die Firewall anpassen sollen.

Ich find deinen Beitrag ehrlich gesagt absolut bemerkenswert. Das bei einer Einrichtung, die vom BMSI als kritisch eingestuft wird, Performance über Sicherheit gestellt wird geht doch auf keine Kuhaut. Warum dann überhaupt so eine Einteilung in kritisch und nicht kritisch? Das schreit doch total nach Mismanagement. Was machen die dann bei nicht kritischer Infrasturktur? Keine Patches einspielen?



Da fährt man doch offensichtlich nach dem Prinzip des kalkulierten Risikos. Boeing lässt grüßen!



Sorry, aber da geht mir echt das Messer in der Tasche auf!

Ist immer eine Risikoabschätzung. Bei uns laufen nur interne Systeme mit internen Systemen zusammen - also Systeme, die ohnehin von den gleichen Leuten genutzt und gewartet werden. Und ohne VPN auch nicht erreichbar sind, da internes Netz. Wenn da jemand drauf kommt, haben wir deutlich schlimmere Probleme.



Problematisch wird sowas nur, wenn auf den Systemen eben Server mit unterschiedlichen "Security-Leveln" laufen, oder eben einfach Kundensysteme auf die man kein Einfluss hat.

Wie laufen denn bei Euch die Audits ab ?

Läuft zurzeit eins, ich bezweifle aber dass das stört, Grund siehe der Absatz hier drüber.

Ich kenne es nur so: Der Betreiber wechselt nur wenn es keine Ersatzteile mehr gibt, er diverse Förderungen vom Staat (zb. Energieeinsparung) bekommt oder er die komplette Software umstellt. Ansonst vermeidet er jeglichen umbau am Lebenden System.







In AT genau das gleiche wie bei dir. Mobility Sparte: Staat, Militär und externe Berater sind der Meinung, dass Spectre und Meltdown keine Gefahr sind.Sind wir uns mal ehrlich, Interessant ist es höchstens für Anlagen die offen im Internet betrieben werden, unautorisierte Programme installiert werden können oder unbekannte Fremdfirmenmitarbeiter auf diesen arbeiten, aber da hat man ohnehin andere Probleme und sollte mal sein Sicherheitskonzept überdenken.







Wird es nicht. Hier wird mit anderen Sicherheitsmaßnahmen gearbeitet. Türkontrollen, Videoanlagen, kein Arbeiten ohne Kunde, Terrorprüfung der MA durch BMI, und und und. Da läuft so einiges mehr im Hintergrund als du dir vorstellen kannst.

Exakt das ist der Kernpunkt. Vertraue ich allen Systemen die auf dem Host laufen? Wenn nicht, und die Kiste ist trotzdem im internen Netz, ist das Problem deutlich kritischer als ein CPU-Bug, mit dem sich Daten auslesen lassen, an die sowieso die meisten in der Firma dran kommen. Denn wenn jemand schon so weit ist, spielt das auch keine Rolle mehr.

 

[Laphonso]

Läuft zurzeit eins, ich bezweifle aber dass das stört, Grund siehe der Absatz hier drüber.

Normalerweise gibt es am Ende aber dann auch genau diese Szenarien: interne Angriffe, die ja weitaus realistischer Sind. DIe Frage ist, "welche" Daten werden dort verarbeitet, welche Zugangsformen gibt es und Protokolle (Anmeldung, Sicherheit im Zugangsbereich bereits vor dem RZ, RFID Cards, Vereinzelungsschleuse, 4 Augenprinzip beim Türen öffnen, zeitlich befristete Zugangsdaten, Logs etc.) .

Ich habe Audits erlebt, da waren auch "die Daten sind nicht im Netz und offline" am Ende mit akuten Sicherheits-Prozessverstößen, z.B. bei lokal gesicherten Daten von Suchtkranken etc.


Das sind aber ganz andere Rahmenbedingungen als die Irrelevanz des Themas für uns Zocker.