Die Republik ist nur so stark wie ihre Community. Werden Sie ein Teil davon und lassen Sie uns miteinander reden. Kommen Sie jetzt an Bord!
Meiner Meinung nach eine weitere Konsequenz au der Privatisierung eigentlich hoheitlicher Aufgaben, oder?
Als ehemaliger Linienpilot wage ich nicht auszudenken, was passiert wäre, wenn diese Panne mitten in einer Rushhour aufgetreten wäre...
Bei den Flugzeugen und dem fliegenden Personal werden doppelte bis dreifache Redundanzen vorgehalten (Gott sei Dank!), aber bei der Flugsicherung herrscht keinerlei System-Redundanz bei gleichzeitiger Personalknappheit und der Auslagerung kritischer IT-Infrastruktur nach Bulgarien - und das bei 87 User-Accounts ohne dass klar ist, wer was wo und wie machen darf ??! Welch profit-geblendete, heilige Einfalt...
Der riesengrosse Elefant im Raum ist ja die privatwirtschaftliche Struktur unserer Flugsicherung. Daraus erfolgt der schleichende Abbau von Redundanz weil 'zu teuer'. Sei dies bei der Technik, sei dies aber auch beim Personal. Standen nicht diese beiden Faktoren ebenfalls im Zentrum der Kollision über dem Bodensee (Überlingen)?
Ach ja, das Militär sollte also 'einspringen'... Da kann man wirklich nur den Kopf schütteln. Dass sich die involvierten Mitarbeiter fragen, ob das überhaupt machbar sei, beweist, dass keine entsprechenden Notfallpläne existieren, oder zumindest nicht geübt werden. Auch hier, wie leider in vielen - gerade auch bundesnahen - Betrieben kriegt man im Pannenfall nur gequirlten PR-Sprech zu hören, mit dem Ziel, das eigene Versagen möglichst zu kaschieren.
Mein Vorschlag: Die Skyguide verstaatlichen und den involvierten Bundesämtern griffige Kompetenzen verschaffen. Was mich allerdings befremdet, ist die Haltung des BAZL, welches fast ein wenig salopp wiederholt, dass dies halt (etwas lose übersetzt) wirtschaftliche Gegebenheiten seien...
Edit: SwissGuide durch SkyGuide ersetzt...
Zit. : "Als ehemaliger Linienpilot wage ich nicht auszudenken, was passiert wäre, wenn diese Panne mitten in einer Rushhour aufgetreten wäre..." .
Ich bin fliegerisch komplett unwissender Laie, aber diese Frage habe ich mir auch gestellt. Wie sähe aus Ihrer Sicht eine solche Realität in etwa aus? Meine Vorstellung ist, dass es da mehr als nur gefährlich würde- könnten da die involvierten Piloten überhaupt noch adäquat damit umgehen?
Die involvierten ControllerInnen müssen damit adäquat umgehen können - den Piloten fehlt dazu das nötige Gesamtbild. Die alleroberste Priorität gilt natürlich der Vermeidung von Kollisionen. Für die Piloten bleibt die Hauptaufgabe, sich der erhaltenen sog. 'clearance limits' klar zu sein und diese peinlichst genau zu befolgen. Dann natürlich - als Sicherheits-Rückfall-Ebene - auch die Beobachtung, sowie das Befolgen der Anweisungen des TCAS-Systems, welches Position Richtung und Höhe der entsprechend ausgerüsteten Flugzeuge in der Nähe anzeigt und bei gefährlicher Annäherung einen Alarm plus eine Anweisung für ein Ausweichmanöver gibt (dies haben z.B. die Russischen Piloten damals bei der Kollision über Überlingen nicht gemacht...). Ach ja, und natürlich zu hoffen, dass diese armen ControllerInnen den Überblick nicht verlieren (ich finde deren Entlöhnung übrigens völlig adäquat, wenn man deren direkte Verantwortung berücksichtigt)! Aber vielleicht sollte man die Löhne und Boni von Geschäftsleitung und Verwaltungsrat der SkyGuide einmal überprüfen. Just saying...
Hier einige laut gedachten Gedanken dazu:
Der Unterschied zwischen 3 Uhr Nachts und, sagen wir, einer Morgen-Rushhour besteht in der Menge der Flugzeuge, resp. deren Nähe zueinander. Ob dieses 'Clear the Sky Procedure' robust genug ist um auch diese Dichte zu bewältigen, oder nicht, kann ich von da aus nicht beurteilen. Sicherlich bedürfen die involvierten Geschwindigkeiten in Flughafennähe (von bis gegen 500 Km/h im Luftraum unterhalb 3'000 Metern) sehr rascher Reaktionen.
Was alles genau ausgefallen ist, geht aus dem Artikel nicht hervor. Allerdings sollte es eigentlich möglich sein, dass von aussen (Frankreich, Deutschland, Italien, Österreich) die Luftlage nach wie vor gesehen werden kann (auch darüber wurde nichts gesagt). Kann sein, dass dies Teil dieses 'Clear the Sky Procedures' ist... Ob dann aber die Koordination mit diesen Zentren zeitnah genug erfolgen kann, oder auch nur schon regelmässig geübt wird, scheint mir daher fraglich (ähnlich wie die Behauptung, dass man dann ja noch auf das Militär zurück greifen könne..).
Sicher ist, dass von der Skyguide her falsche, unvollständige und daher irreführende Informationen heraus gegeben wurden. Und das ist für mich inakzeptabel (aber bei profit-orientierten Unternehmen heute leider 'Standard') . Und dass eine Flugsicherung zu dieser Art von Unternehmen gehört, ist der eigentliche Skandal.
Meiner Meinung nach eine weitere Konsequenz au der Privatisierung eigentlich hoheitlicher Aufgaben, oder?
Zur Aufheiterung zuerst ein Video: «‹Lust auf Leistung› by swisscontrol». Dies ist wohl in den 90er entstanden in der Phase der Privatisierung und bestätigt vielleicht Ihre These.
Daraus erfolgt der schleichende Abbau von Redundanz weil 'zu teuer'. Sei dies bei der Technik, sei dies aber auch beim Personal. Standen nicht diese beiden Faktoren ebenfalls im Zentrum der Kollision über dem Bodensee (Überlingen)?
Das ist richtig. Danach wurden «single manned operations» abgeschafft. Vielleicht sollte man jetzt «single data centers» abschaffen? Uns wurde aber versichert dass ein «Clear the Sky» zwar brenzliger wäre im Hochbetrieb aber schon machbar. Radar und Voice funktionierten noch am 15. Juni.
Ob eine Verstaatlichung viel bringen würde bin ich mir unsicher. Skyguide gehört vollständig dem Bund. Airlines und Flughäfen sind nur symbolisch beteiligt für den Informationsaustausch.
Ein Kapitel was wir nicht aufgemacht haben: Eigene Software Entwicklung und Skysoft – Skyguide entwickelt sein System grösstenteils selbst, verkauft einige Komponenten weiter und hatte da wohl auch mal grössere Ambitionen.
Danke für den Link zum Filmli Herr Preusse! Der Enthusiasmus, mit dem damals hüben wie drüben Privatisierungen schmackhaft gemacht wurden, ist aus heutiger Sicht erheiternd ;-)
Allerdings scheint mit dieser Enthusiasmus und fast grenzenloser Optimismus schon damals 'nur für's Schaufenster' gedacht gewesen zu sein... In allererster Linie ging und geht es darum, bei möglichst geringen Kosten möglichst viel Gewinn zu erwirtschaften. Und genau da liegt ja die Krux...
Es ist ja genau dieser Kostendruck, der dazu führt, dass 'Kurven geschnitten' werden (müssen). Anders kann man es sich ja nicht erklären, warum es z.B. keine, zur produktiven Umgebung parallel laufende Testumgebung gibt, wo Patches, Updates, Verbesserungen, usw. zuerst gefahrlos getestet werden können, bevor diese ausgerollt werden? So würde das Dilemma, ob man aus Sicherheitsüberlegungen mit Updates zuwarten sollte, oder ob diese lieber grad sofort implementiert werden sollten, gar nicht erst entstehen. Aber eben: Redundanzen kosten.
Also, ich denke schon, dass eine Rück-Verstaatlichung der Flugsicherung viel bringen würde. Und sei es nur, dass die Schweizer Behörden eine wesentlich direktere Überwachung und Durchgriff hätten. Und sofern man die Flugsicherung nicht gewinn-orientiert aufstellt, würden die Endpreise vielleicht sogar eher tiefer liegen...
mir geht es- auch ohne Pilotinnen-Erfahrung- genau so. Die Finanzierungssstruktur der Skyguide (Fluggebühren) ist für mich fragwürdig, ebenso dass Fragen wie die Geo-Redundanz und solche Risiken dann einfach dem Flugsicherungsunternehmen überlassen und damit "privatisiert" wird. Einem privaten Unternehmen in Bundeshand, das gezwungen ist, zu sparen...
Absolut einig mit Ihnen, Frau Fichter!
Fragt sich nur, warum der Eigner dieses 'Unternehmens in Bundeshand' dieses zwingt, zu sparen - in einem solch sicherheits-relevanten Bereich....
Mir scheint, dass dies Auswüchse davon sind, weil alle diese Unternehmen in Bundeshand nur deshalb teil- privatisiert wurden, um via Profit mehr Einnahmen für den Bund zu generieren (via Gewinnerwartungen an Bundesbetriebe!). Oder anders ausgedrückt: Damals hat der ungebremste Neo-Liberalismus voll auf die Politik durchgeschlagen. Dessen verunglückte Konsequenzen sehen wir dann hier und anderswo...
Diese Mechanismen sind doch eigentlich nichts anderes als 'versteckte Steuern', oder? Kann es wirklich Sinn und Zweck von Bundesbetrieben sein, Gewinne zu Handen der Bundeskasse zu generieren, anstatt deren Dienstleistungen zu Selbstkostenpreisen der Bevölkerung, den SteuerzahlerInnen, zur Verfügung zu stellen?
Ja, ich weiss, das tönt (mittlerweile) ziemlich naiv... zudem schweife ich nun doch definitiv vom Thema ab.
Auf alle Fälle vielen herzlichen Dank für einen einmal mehr sehr interessanten Beitrag!
Sehr gute Reportage, die wieder einmal einen wunden Punkt offen legt. Was mich - unter Vorbehalt des nachstehenden Kommentars -beruhigt, ist, dass „clear the sky“ wenigstens funktioniert. Dass aber das BAZL, das UVEK und die EFK der Skyguide vorhalten muss, was alles faul ist in ihrem Laden, gibt zu denken.
Hervorragend aufbearbeitet wie immer, danke. Warum darf eigentlich die Public Cloud für solche Projekte immer noch nicht eingesetzt werden? Man kann nicht mal mehr behaupten, das seien keine Schweizer Firmen. Google und Microsoft beschäftigen tausende Mitarbeiter in der Schweiz und betreiben mehrere lokale Datacenter.
Private Miniclouds kommen nie an die Sicherheitsstandards und Aussfallsicherheit dieser Anbieter heran. Da wäre auch mehr Know-How bei der Gesetzgebung gefragt, dass man sinnvolle Auflagen macht und nicht nur pauschal verbietet.
Hmmm... ich weiss nicht... es ist zwar schon richtig, dass Google, Micro$oft, Amazon, usw. in der Schweiz tausende von MitarbeiterInnen beschäftigen, aber die Spielregeln werden definitiv nicht hier gemacht.
Vielmehr plädiere ich für die Errichtung einer Schweizer Cloud, gemanaged durch Schweizer Firmen und das Ganze gehostet in der Schweiz. Und sei das auch 'nur' für die bundesnahen Betriebe, welche hoheitliche Aufgaben zu verrichten haben... ABer nein, wir involvieren dazu sogar noch die Chinesen! kopfschüttel
Ich zweifle keine Sekunde daran, dass wir in der Schweiz genügend qualifiziertes Personal und Know-How haben, um das professionell umzusetzen. Es wäre sicher tausend Mal sicherer und zuverlässiger, als so eine Minicloud, welche von irgendwo in Bulgarien gehostet wird.
Diese «Minicloud» ist eine sogenannte Private Cloud, welche die selben Technologien verwenden kann, aber ausschliesslich in der Firma / für diese Firma betrieben wird.
Vorteil: eigene Ressourcen, Reservationen von Kapazität möglich, Anbindung an Netzwerk unter Umständen schneller/direkter
Nachteil: skaliert nicht gleich (da man selber physische Server bestellen muss), Know How für Serverbetrieb muss vorhanden sein.
Diese «Minicloud» wird nicht in Bulgarien gehostet, sondern von dort überwacht. Etwas, das durchaus üblich ist. So haben etliche Schweizer RZ-Betreiber ihre Überwachung in den Osten ausgelagert. Das kann sehr gut funktionieren, da Routine-Aufgaben auch dort zuverlässig (und halt günstiger) durchgeführt werden können.
Die Schwachstellen sind dann eher im komplexen Störungsfall, weil dann teilweise die Sprachbarrieren hochkommen und komplexe Abhängigkeiten dort nicht bekannt sein können.
Also, ich möchte widersprechen, dass professionelle "Miniclouds" nicht an die Standards der "Grossen" heranreichen. Den Grossen fehlt die Flexibilität, die es für diverse Branchen braucht, wenn wir von mehr als nur dem Hosting von Dokumenten und Email sprechen, sondern von sehr speziellen Applikationen wie hier bei Skyguide. Sowas kann eine private Cloud sehr viel besser anbieten.
Und so ganz am Rande: DXC ist alles andere als ein kleiner Anbieter, nur der Name ist nicht sehr bekannt. Kleiner Hinweis: das ist die ausgegliederte Service-Spart von HP/HPE mit einer Fusion mit CSC, weltweit über 100'000 Mitarbeiter. Die wissen eigentlich sehr genau, wie man sowas betreibt. Mich wundert, dass dort niemand gegen die "nur ein Datacenter-Lösung" vorgegangen ist.
CSC (bzw. die früher von CSC gekaufte DynCorp) ist bekannt für die Organisation von Flügen nach Guantánamo Bay:
https://www.theguardian.com/busines…-rendition
Wieso sollte dort jemand gegen die "nur ein Datacenter-Lösung" vorgegangen sein? Opportunisten führen alles aus.
Sie müssen folgendes bedenken: Kontrollzentren, wie es sie in der Luftfahrt, den Bahnbetrieben oder dem Stromnetz gibt, sind anfällig auf Latenzzeiten. Die Datenquelle (zb. Messquellen im Stromgrid) sind lokal. Wenn die Daten dann zuerst raus in eine entfernte Cloud geschickt werden und dann wieder zurück zum Display im Kontrollzentrum steigt die Latenz mit der ein Mitarbeiter die Daten aufbereitet bei sich sieht. Einige Millisekunden mehr oder weniger Verzögerung in der Aufbereitung können in solchen Anwendungsfällen bereits viel ausmachen. Noch schlimmer wird es, wenn die Anbindung zwischen ihnen und der entfernten Cloud packet loss hat (dh. aufgrund temporärer Überlastung nicht mehr zuverlässig übertragt). Sowas kann in einem Kontrollzentrum massiv zu Problemen führen. Darum ist es sinnvoll, alles lokal zu haben ohne Umwege in der Datenübertragung.
Die tausenden von Mitarbeitern in der public Cloud kennen sich bis und mit Ebene des Betriebssystems sowie mit Standardapplikationen aus. Bei den oben drauf laufenden, spezialisierten Applikationen werden die ihnen nicht helfen können. Für eine Applikation zb. zur Auswertung von Messdaten im Stromgrid oder der Aufbereitung von Radardaten wird ihnen Microsoft keine Spezialisten ausbilden. So etwas ist zu selten, als dass es sich für den Anbieter der public Cloud lohnen würde.
Das Problem bei der Microsoft Azure Cloud im Speziellen ist ja gar nicht, dass die beiden Schweizer Datacenter Nord (Zürich) und West (Genf) nicht 'sicher' wären, sondern verschiedene Unternehmen (insb. bundesnahe) stören sich daran, dass die amerikanische Justiz (theoretisch) mittels CLOUD Act (Clarifying Lawful Overseas Use of Data Act) Zugriff auf Datenbestände nehmen könnte, da Microsoft eine US Amerikanische Firma ist. Die realistische 'Gefahr' für Schweizer Unternehmen wurde übrigens von RA Rosenthal im Dokument 'Cloud Lawful Access' aus juristischer Sicht sehr detailliert diskutiert.
Sehr cool und irgendwie auch sehr beängstigend....
Immer wenn ich "historisch gewachsen" lese bin ich verärgert, denn das sind keine "Naturphänomene" die "halt so passieren". Jemand hat bewusst die Entscheidung getroffen, Dinge so zu tun, und hat die damit verbundenen Risiken in Kauf genommen.
Das mit solchen Worten (wie "gewachsen") zu verschleiern finde ich nimmt die Entscheidungsträger*innen aus der Verantwortung.
Kann ich verstehen. Im Kontext von Skyguide würde ich aber auch noch das Konzept «Drifting into Failure» bedenken. Viele kleine (bewusste) Entscheide können zu grossen (unbewussten) Problemen führen. Dieses Konzept hatten Skyguide Mitarbeitende aufm Radar. Es scheinen wirklich viele gute Leute dort zu arbeiten. Aber ja die Entscheidungsträger*innen haben rückblickend aus meiner Sicht definitiv Fehler gemacht.
Ich meinte das nicht speziell auf Skyguide bezogen, also ich wollte sie da nicht speziell hervorheben, oder ihnen speziell schlechte Strukturen vorwerfen, oder gar unfähige Mitarbeiter unterstellen.
Die Anzahl der Rechenzentren ist für sich genommen noch kein Qualitätsmerkmal. Wichtiger sind Vorgaben wie die max. Reaktionszeiten (zb. wann spätestens Pikett vor Ort sein muss), die Verfügbarkeit (max. akzeptable Ausfallrate) oder die Time to restore (max. Dauer zur Auflösung einer Störung). Der Auftraggeber gibt dies normalerweise dem Auftragnehmer in einem Service Level Agreement (SLA) vor. Die Einhaltung eines SLA ist auch etwas messbares (zb. durch Quartalsreport der Ausfallrate oder Statistiken über Reaktionszeiten). Hier wäre der Auftraggeber von skyguide gefordert ein SLA festzulegen und vorallem die Messwerte periodisch einzufordern.
Wenn wir es vergleichen: Eine geforderte Time to restore von 24 Stunden und eine geforderte Time to restore von 30 Minuten sind beides mit 2 Rechenzentren machbar. Die zwei Varianten haben von der Qualität her jedoch komplett unterschiedliche Dimensionen.
Wenn das einzige Rechenzentrum abbrennt, kann ich dann die unterschriebenen SLA's nicht gleich direkt in selbiges Feuer werfen? (Etwas salopp ausgedrückt, aber Sie verstehen den Punkt?)
Oder werden solche Fälle ebenfalls in den Service Level Agreements festgehalten (Notwendige Zeit für den Aufbau eines gleichwertigen Rechenzentrums?)
Wenn der Auftraggeber festlegt, dass sie eine Time to restore von 24 Stunden sicherstellen müssen, dann kann ihre Entscheidung für ein "cold standby" fallen. Im zweiten Rechenzenter läuft alles leer und sie gehen manuell wieder alles in Betrieb nehmen (schliesslich gibt ihnen ihr Auftraggeber 24 Stunden Zeit).
Wenn ihr Auftraggeber festlegt, dass sie eine Time to restore von 30 Minuten erbringen müssen, dann wird der Entscheid tendenziell auf einen "hot standby" fallen. Zwei (oder sogar drei) Rechenzentren sind ständig aktiv und im Falle einer Störung können sie alles automatisiert und nach Drehbuch innert wenigen Minuten hochfahren.
Als Auftraggeber sollte sie daher immer solche Kennzahlen vorgeben (und nicht nur eine bestimmte Anzahl Rechenzentren verlangen). Idealerweise verlangen sie auch die Durchführung einer halbjährliche Übung und prüfen, ob die Zeiten eingehalten werden können.
Einverstanden, solange die Zahl grösser als 1 ist. Wünschenswert wäre natürlich 30 Minuten und nicht 24 Stunden.
Laut EFK Bericht vom Februar ist man heute wohl auch weit von 24 Stunden entfernt – man hat heute nur ein Rechenzentrum und kein Disaster-Recovery-Plan:
Fehlende Business-Continuity- und Disaster-Recovery-Pläne
Trotz erhöhtem Fokus auf die Zusammenarbeit mit dem Partner DXC bestehen aktuell keine spezifischen BCP oder DRP für die daraus resultierenden Risiken. Ein physischer Ausfall der Virtualisierungsinfrastruktur kann zu einem Ausfall von kritischen Anwendungen führen. Wenn ein System bei einer Störung ausgetauscht werden muss, wird DXC einen weiteren Partner beauftragen, dies vor Ort durchzuführen. Die Mitarbeitenden dieses Partners können nur in Begleitung und unter der Aufsicht von speziell ausgebildeten «Air Traffic Safety Electronics Personnel» (ATSEP) der Skyguide arbeiten.
Beurteilung
Trotz erhöhtem Fokus auf die Zusammenarbeit mit DXC besteht aktuell kein BCP oder DRP mit DXC. Ein physischer Ausfall der von DXC betreuten Virtualisierungsinfrastruktur bedingt eine enge Kooperation und klare Koordination zwischen drei Parteien (Skyguide, DXC und deren Partner). Die Zusammenarbeit mit zwei weiteren Parteien bei einem Vorfall erhöht die Komplexität erheblich und wird am besten durch einen DRP und/oder einem BCP geregelt.
Empfehlung 6 (Priorität 1)
Die EFK empfiehlt Skyguide, im Rahmen der geplanten Weiterentwicklung der Disaster-Recovery-Pläne (DRP) die Thematik der externen Dienstleister spezifisch zu regeln.
Die Empfehlung ist akzeptiert.
Stellungnahme der Skyguide
Vorschlag: Im Rahmen der aktuellen Entwicklung der Disaster-Recovery-Pläne (DRP) werden externe Dienstleister wie DXC ebenfalls miteinbezogen.
Ja, das Statement aus dem Bericht der EFK stimmt nicht besonders optimistisch.
Ich muss allenfalls noch präzisieren, weshalb ich meinen Kommentar gemacht habe. Beruflich bin ich häufig in Projektausschreibungen und Vertragsverhandlungen im Outsourcing involviert. Die Anzahl Rechenzenter ist nie ein Aufhänger dort. Sondern eben die vom SLA verlangte zu erbringende Qualität. Und daher finde ich die Forderung im Artikel falsch. Der Start sollte darin liegen, dass jemand die Vorgabe eines SLA macht, was zb. eine Forderung an die Politik sein könnte.
Die Anzahl Rechenzenter ist mitunter auch kein Aufhänger in solchen Verhandlungen weil es sich dabei um keinen standardisierten Begriff handelt. Es gibt keinen Standard, auf den sie sich hier abstützten könnten. Sie sind daher frei, einige Rechner bei ihnen in den Keller zu stellen und dies dann als Rechenzenter zu bezeichnen.
Wenn die Pönalen günstiger sind als die Georedundanz, gibts keine Redundanz. Die in der SLA vereinbarten Werte sind nie eine Garantie. Da können Sie dann gerne nach einem katastrophalen Ausfall sagen "aber in den Veträgen stand dass das nicht passieren darf!". Die entsprechenden Anbieter sind nur wirtschaftlicher, weil sie mehr Risiken eingehen.
In der Praxis gibt es eben deshalb regelmässige Testläufe, bei denen real der Stecker gezogen und gemessen wird, ob die Wiederherstellung so schnell wie erwartet möglich ist. Und ohne SLA ist nicht definiert, ob man ein Ergebnis eines Testlauf nun als "bestanden" oder "nicht bestanden" beurteilen will. Ein SLA ist auch Voraussetzung überhaupt solche Tests anordnen zu dürfen, denn so wird das vereinbart.
Schön wäre es, nicht nur die offensichtlichen - soweit wir das überhaupt beurteilen können - Mängel offen zu legen, sondern auch das ALLERWICHTIGSTE, das Skyguide vollkommen und diskussionslos richtig gemacht hat, zu loben: Nämlich dass ohne Rücksicht auf Imageverlust oder wirtschaftliche Auswirkungen, erst mal zur Sicherheit der Menschen, folgerichtig der komplette Luftraum gesperrt wurde! Über alles andere kann man ja diskutieren, aber nicht über Menschenleben.
Zu den Software Aktualisierungen: Es ist im Allgemeinen mal völlig verständlich, Updates nicht sofort zu installieren, sondern über eine gewisse Zeit vorgängig zu testen. Gerade Microsoft zeigt uns mit ihren Updates ja immer wieder, dass neben der Fehlerbehebung auch neue, teils kritische Probleme mit eingebaut werden! Das möchte man im Flugverkehr sicher nicht erst in der Luft merken, oder?
Und noch etwas zur Informationssicherheit: Gerade schlau war es von Euch (Republik) ja auch nicht, den Hersteller von HW-Komponenten der Skyguide noch weiter zu verbreiten: " der Hersteller Extreme Networks....". Genau solche öffentlich zugänglichen Informationen erleichtern Hackern das Leben zusätzlich und völlig unnötigerweise!
Dass das Skyguide-Personal richtig reagiert hat, haben wir ja geschrieben... deshalb muss ja die IT-Infrastruktur trotzdem kritisch untersucht werden (ein Wunsch den wir von allen Seiten, von den LotsInnen und auch vom technischen Personal gehört haben übrigens). Extreme Networks als Hersteller zu nennen (die ja nichts falsch gemacht haben, sondern ein Update zur Verfügung stellte), ist von öffentlichem Interesse. Ebenso dass die Mini-Cloud von DXC betrieben wird.
Ich bin halt der Meinung, dass in einer seriösen Berichterstattung, wie sie die Republik ja lebt, überaus wichtige und positive Punkte durchaus ebenfalls gut erkennbar hervorgehoben werden dürften. Immerhin lässt ja die Unternehmenskultur von Skyguide (wie ich in diesem Kontext annehmen darf) wenigstens zu, dass eine Notfallmassnahme auch wirklich getroffen werden darf. Da gibt es ganz andere Beispiele in jüngerer Vergangenheit, die zu Katastrophen geführt haben ....
Ich sage ausserdem auch nicht, dass Extreme Networks etwas falsch gemacht hat. HW-Informationen (Hersteller, Modelle etc.) zu Unternehmen gehören in der heutigen Zeit einfach grundsätzlich nicht an die Öffentlichkeit. Sorry, aber an diesen Details sehe ich kein öffentliches Interesse...
Es sind oft die vielen einzelnen Puzzle-Teile, die zusammengefügt den Erfolg von Hackern zumindest massgeblich unterstützen.
Nur um nicht missverstanden zu werden: Ich will nicht die aufgedeckten Missstände beschönigen und auch Eure wertvollen Recherchen nicht in Frage stellen. Ich weiss aber auch, dass zwischen Weiss und Schwarz eine ganze Reihe Grautöne existieren.....
Da bin ich anderer Meinung. Erstens erwischt man eh nicht alle Szenarien beim Testen, und zweitens sind Updates ein Beheben von bestehenden Fehlern - das heisst, das System macht ohne das Update nicht, was es sollte.
Ja, mal testen ist gut aber im Text steht "seit längerem".
Konkret wurde das Update 2 Jahr vor dem Vorfall veröffentlicht.
Ich bin mit Ihnen, Skyguide hat insofern richtig reagiert, dass Sie diese Prozedur eingeleitet haben.
In einem Produktivsystem Updates einspielen ist ein Albtraum. Darum gibt es ja auch Netzwerkseparierung: kritische Systeme, die man nicht mit vernünftigem Aufwand/Risiko updaten kann sind vom Internet getrennt*. Alles was "von Aussen" zugänglich ist muss aber ohne Rücksicht auf Verluste sofort aktualisiert werden.
Und wegem dem HW-Hersteller: Wenn jemand das wissen möchte, dann wäre das ja einfach herausfindbar. Schauen Sie mal bei einer beliebigen Firma Ihres Interesses in den Altpapiercontainer auf die Kartonschachteln. Und es ist ja auch nicht so, dass namhafte Hersteller keine Sicherheitslücken hätten... (Hallo@Cisco) Security through obscurity haben wir glaub schon länger hinter uns.
* Sagen wir halbdurchlässig. Wirklich physisch getrennt ist es ja sehr selten.
Klar kommt man auch sonst zu Informationen, wenn man es darauf anlegt, da gebe ich Ihnen völlig recht. Das Durchwühlen von Altpapierbehältern ist allerdings nicht ganz so einfach möglich, Informationen aus den Medien zusammentragen hingegen ist ungleich einfacher (z.B tagtägliche Arbeit der Nachrichtendienste)
Updates einzuspielen, hat mit Innovation nichts zu tun - vielleicht gibt es neue Features, vor allem aber geht es um Sicherheit und Stabilität. "Never change a running system" bedeutet nicht "never update a running system"..
Grüezi Herr Alexander Finger. So war die Aussage nicht gemeint, mehr: die Zeichen stehen auf Vernetzung und Virtualisierung (so versteht Skyguide "Innovation"). Dass die Updates nicht vernachlässigt werden sollte, versteht sich von selbst. Und hiermit eben auch das Dilemma der Skyguide: mehr vernetzen und virtualisieren, aber der Anspruch auch viel zu testen vorab in der Validierungsumgebung, bevor überhaupt ein Update aufgespielt wird (und eher zu warten mit Updates aufspielen). Das beisst sich eben meiner Meinung nach.
Liebe Frau Fichter
Danke für die Erläuterung! Um den Antagonismus aufzulösen, gibt es Methoden und Architekturen, die beide Bedürfnisse befriedigen - einige werden hier in den Kommentaren schon angesprochen.
Das verstehe noch nicht ganz, was ist eine "defekte Routingtabelle"?
"In der internen Analyse wird der Ausfall auf eine defekte Routingtabelle zurückgeführt."
iptables hat sicher jeder Netzwerkadmin schonmal verkonfiguriert, aber eine Routingtabelle geht ja nicht einfach so von selber kaputt? Oder was muss man sich darunter vorstellen?
Routing Tables in Switches:
https://www.geeksforgeeks.org/routi…r-network/
Diese waren in einem «inconsistent/undefined» oder auch «corrupted» status. Ein Neustart reichte allerdings um diese neu und korrekt zu generieren. Wie diese in den defekten Status kamen ist, soweit wir wissen, nicht eindeutig geklärt. Im internen Bericht wird aber explizit betont dass eine solche Korrumpierung nicht im Zusammenhang mit Cyberangriffen steht. Am naheliegendsten ist ein Bug in der Firmware. Aber könnte ja auch ein «Bit Flip» gewesen sein 🤷
Breaking: Nach einem technischen Zwischenfall im Juni hat Skyguide beschlossen, ihr Notfallprozedere Clear the sky dauerhaft auf Freizeitreisen anzuwenden.
«Unsere oberste Maxime lautet ‹Safety first›. Da der private Luftverkehr unverhältnismässig zur Zerstörung unserer Lebensgrundlagen beiträgt, haben wir entschlossen, zur Sicherheit unserer Passagiere den privaten Flugverkehr bis auf Weiteres einzuschränken.» lässt Pressesprecher Vladi Barrosa verlauten. Skyguide verleihe damit seinem Versprechen Nachdruck, Umweltschutz als «integralen Bestandteil» ihres Auftrags zu betrachten.
Angesprochen auf weitere IT-Pannen winkt Barrosa ab: «Das Schöne ist ja, dass damit nicht nur die Menschen, sondern auch unsere Server aufatmen können.»
(Eine Parodie 😔)
Der Flugverkehr stösst im einstelligen Prozentbereich des Gesamt-CO2 aus.
Und: der Flugverkehr stösst pro Kilometer weniger CO2 aus als der Autoverkehr.
Diese öffentliche Brandmarkung verdient der Flugverkehr nicht. Die echten CO2-Ausstosser sind die Energieindustrie in der Stromproduktion und einige der grössten Energieverbraucher sind nebst Industrie die Datencenter. Nicht der Flugverkehr.
Ein berechtigter Einwand, auf den Wissenschaftsjournalist Matthias Plüss vom Tagesanzeiger eine prägnante Antwort parat hat:
Nur 2,5 Prozent der weltweiten CO2- Emissionen stammen vom Fliegen. Wäre es nicht sinnvoller, etwa beim Heizen zu sparen?
Die 2,5 Prozent stimmen. Aber sie sind irreführend. Flugzeuge erhitzen die Erde nicht nur mittels CO2, sondern auch durch die Kondensstreifen: Diese mindern die Wärmeabstrahlung der Erde. Richtig gerechnet, trägt der Flugverkehr global 5 Prozent zur Erwärmung bei. In der Schweiz sind es sogar 19 Prozent. Was daran liegt, dass wir ein extremes Vielfliegervolk sind.
Natürlich ist es sinnvoll, auch beim Heizen oder der Ernährung zu sparen. Aber es ist viel schwieriger. Um einen einzigen Retourflug nach Madrid auszugleichen, muss man die Temperatur in einem Einfamilienhaus mit Ölheizung einen ganzen Winter um zwei Grad reduzieren (oder ein Jahr lang auf Fleisch verzichten). Bei einem Retourflug nach St. Petersburg sind es schon drei Grad (oder für ein Jahr zum Veganer werden). Das reicht aber noch nicht. Wohnen in dem Einfamilienhaus drei Personen mit durchschnittlichem Flugverhalten, müssten sie die Ölheizung dauerhaft komplett abstellen, um all ihre Flüge zu kompensieren.
Es bleibt dabei: Für Schweizerinnen und Schweizer ist es am sinnvollsten, beim Fliegen anzusetzen. Eine Trendwende ist aber nicht in Sicht: Die Passagierzahlen am Flughafen Zürich lagen 2019 in jedem Monat über dem entsprechenden Vorjahresmonat.
Im selben Artikel werden übrigens auch die von Ihnen erwähnten Datencenter angeschnitten («Stimmt der Slogan «Streaming ist das neue Fliegen»?»).
Können Sie sich vorstellen, mit diesen neuen Informationen die Bedeutung des Flugverkehrs anders einzuschätzen?
Adrienne Fichter und Thomas Preusse, da weiss man schon vor dem Lesen was kommt 😁.
Wieder ein guter Artikel, vielen Dank.
Ich finde die Artikel die ihr schreibt auf ihre eigene Art sehr unterhaltsam (liegt allenfalls daran, dass ich in der IT arbeite).
Bezüglich der Updates gibt es Viele die finden lieber vorsichtig sein und nicht zu häufig machen.
Ich bin da eher Gegenteiliger Meinung. Um so häufiger man sie macht umso problemloser werden sie.
Klar könne sie neue Probleme bringen, in der Regel kann man sich darauf aber vorbereiten.
Je nach dem mehr Hardware oder sonstiger Redundanz.
Es ist wie bei der Feuerwehr oder wohl auch den Fluglotsen, wenn man es häufig übt sitzen die Handgriffe dann auch wenn es mal wirklich schief geht.
Würde ich mittlerweile auch unterschreiben (früher nicht). Seit wir halbjährliche Leitsystem-Updates machen geht das bei laufendem Betrieb recht routiniert durch, früher (und an anderen Standorten mit längeren Zyklen) war das immer ein Riesenmurks.
Merci. Wir unterhalten Sie gerne :-)
Üh, die Republik wird auf golem.de erwähnt. Keine schlechte Publicity.
Noch eine Frage: Weiss jemand, was die problematische Netzwerkkomponente genau war? (Modell, Serie,...) Es werden relativ viele Begriffe verwendet (Netzwerkcomputer, Netzwerkkomponente, Switch,...). Grundsätzlich war es ein Layer-3-Switch, oder?
Das genaue Modell kann ich Ihnen leider nicht sagen. Es war ein Extreme Networks Switch der Teil eines Switch Clusters in Dübendorf war.
Extreme Networks hat anfang Jahr folgendes publiziert zur Zusammenarbeit mit Skyguide:
Skyguide, the leading provider of air navigation services in Switzerland and delegated airspaces, needed a network that would enable more efficient deployments of multiple wide area security zones with strong support for multicast traffic. Extreme was selected to deliver switching and management solutions including Extreme Fabric Connect, making Skyguide's network infrastructure more flexible, simpler to deploy, and easier to automate.
Ein interessantes Detail darin: multicast. Macht das ganze sicher auch nicht einfacher.
Danke! Jetzt kann ich mir etwas mehr darunter vorstellen. Das braucht ein starkes Nervenkostüm, so als Techie mitten in der Nacht ohne gross Befugnisse (aber mit grossen Erwartungen anderer) vor so einem Ding zu stehen. Aber wohl nichts gegen das Nervenköstung, welches die Skyguide-Leute benötigen🙈
Danke fürs detaillierte nachhaken. Ich fragte mich damals sehr ob dies redundant ausgelegt war oder nicht. Bei solche wichtigen Systemen wäre ohne Geo Redundanz als Sofortmassnahme eine lokale Redundanz wichtig. Solche Core Switches (das Wort "Netzwerkcomputer" hat mich sehr irritiert, kein Mensch nennt einen Switch so, ich weiss ihr wollt möglichst einfache IT Sprache aber der Begriff ist schlicht irreführend und auch gemäss Wikipedia kein Synonym) sollten immer redundant als Cluster ausgelegt sein, damit ist es dann eben auch möglich einen Update zuerst nur auf einem aufzuspielen um zu sehen ob alles weiter sauber läuft.
Ich hoffe es wurde etwas daraus gelernt und auch Remotemässig ein Netzwerk aufgebaut welches nicht über die normalen Switches läuft damit man noch Remote zugreifen kann wenn so einer ausfällt. Oder woran lag es konkret, dass kein Zugriff mehr möglich war, wirklich auch an diesem einen Switch?
Ebenfalls bleibt die Frage offen ob das Militär effektiv hätte übernehmen können. Betreibt das Militär eine Flugüberwachung welche die Kapazität sowie die Ausbildung hätte um die zivile Überwachung zu übernehmen?
Besten Dank für den sehr informativen Artikel und die „technische“ Ursachenanalyse zum Ereignis. Interessant ist für mich, dass in solchen mit hohen Risiken verbundenen Operationen (grosse Auswirkung, kleine Eintritswahrscheinlichkeit eines Ereignisses) aber auch einer genau definierten Regulation wie man mit Risiken umgehen soll ( siehe auch https://www.skybrary.aero/articles/risk-management) , solche Gefahren und Risiken nicht besser vor dem Ereignisfall erkannt und reduziert wurden/werden (Proaktives Risikomanagement). Dadurch ist zu hinterfragen wie die zuständige Aufsichtsbehörde BAZL UVEK Ihre Aufsichtspflicht in diesem Bereich wahrgenommen hat?
Gute Frage. Was wir wissen: Das BAZL führt immer wieder Audits durch und stellte bereits vor dem Vorfall etliche «Nichtkonformitäten» (Non-Confomity Statement) fest und forderte «Korrekturpläne» (Corrective Action Proposal). Details zu den ausstehenden Korrekturen wollte das BAZL nicht geben:
Die Umsetzung des Korrekturplans ist ein laufendes Verfahren. Zu laufenden Verfahren können wir keine Auskunft geben.
Untätig sind sie auf jeden Fall nicht.
Medienmitteilung UVEK zur Thematik: https://www.uvek.admin.ch/uvek/de/h…92306.html
- Mitglied werden
- Angebote
- Gutschein einlösen
- Anmelden
Republik AG
Sihlhallenstrasse 1
8004 Zürich
Schweiz