Und weil schon grad am Standard bin: http://derstandard.at/1395056818793/Fuer-Geldautomaten-tickt-die-Uhr---Aus-f...
Der Artikel strotzt etwas von Bullshit, aber grundsätzlich stellt sich doch die Frage ob Banken nicht mal eine echte IT-Strategie machen sollten, statt das Mizitant-Betriebsystem auf ihre Hardware zu frickeln.
"Denn nun muss jedes Haus einen Wartungsvertrag mit Microsoft abschließen, wenn es keinen Systemabsturz bei der Geldausgabe riskieren will."
Würde mich interessieren welche Art von Support die Banken vorher hatten und von wem? Schaltet XP nach Ablauf der Wartung auf crashy-mode?
"Wincor Nixdorf bietet seinen Kunden zudem eine spezielle Software an, die die Windows-XP-Automaten unangreifbar gegen Schadsoftware von außen machen soll, wie der Sprecher sagt."
Ab 10 Lizenzen ein Flasche snake oil gratis.
lg, Florian
On Fre, 2014-03-21 at 09:51 +0100, Florian Schweikert wrote:
Und weil schon grad am Standard bin: http://derstandard.at/1395056818793/Fuer-Geldautomaten-tickt-die-Uhr---Aus-f...
Der Artikel strotzt etwas von Bullshit, aber grundsätzlich stellt sich doch die Frage ob Banken nicht mal eine echte IT-Strategie machen sollten, statt das Mizitant-Betriebsystem auf ihre Hardware zu frickeln.
Die Bankomaten haben ja nichts mit den Banken zu tun - die waren aus historischen Gründen (war wohl etws Platz vonnöten und die Bargeldmengen dort drin sind auch nicht so klein) dort montiert, aber jetzt stehen auch welche in Supermärktme rum -, sondern werden von Europay IIRC "betrieben". Hmm, die heißen jetzt wohl https://www.paylife.at/ (weil http://www.eurppay.at/ dorthin redirected) ...
Und wie die das alles designen und bauen bzw. bauen lassen ....
"Denn nun muss jedes Haus einen Wartungsvertrag mit Microsoft abschließen, wenn es keinen Systemabsturz bei der Geldausgabe riskieren will."
*muss*?! Ich krieg' halt keine Updates mehr. Am Desktop von $SEKRETÄRIN ist das (hoffentlich) egal, halt mit Treibern wird es bei neuer Hardware immer mühsamer. Ist sowieso Techie-Schrott, was die da schreiben ...
So strategisch hätte man sich schon vor Jahren (weil XP ist schon vor Ewigkeiten zum 1. Mal abgekündigt worden) überlegen können: - Läuft die Bankomat-User-Interface-Applikation "as is" unter Wine? - Wie mühsam ist das portieren/umschreiben auf $XXX (und das $XXX könnte etwas sein, daß es vllt. nicht nur bei Monopolisten gibt). Und wenn es PHP oder TK oder perl ist (oder meinetwegen Java) - soooo super-toll oder gar ressourcenfressend ist das Bankomat-UI auch nicht, daß man das dafür ganz nah am Graphik-Subsystem und Widget-Set schreiben muß. Das könnte man auch als JavaScript bauen .... Und dann kann man die alte Hardware vermutlich noch Jahrzehte weiterbetreiben ....
Würde mich interessieren welche Art von Support die Banken vorher hatten und von wem? Schaltet XP nach Ablauf der Wartung auf crashy-mode?
Zum einen: Das willst Du nicht wissen, was da z.T. intern abgeht. Gschichtln dazu gibt es nicht schriftlich und nicht nüchtern;-)
Zum anderen: Ich hab (auch) k.A., ob und welche sonstigen Spezialregelungen/vorschriften/"standards" es im Banken(un)wesen u.U. noch gibt. Und konkret wird es Exklusivverträge u.ä. geben, daß auf einmal alles superkompliziert ist, weil der Lieferant den Kunden nicht von der Leine lassen wollen wird .....
"Wincor Nixdorf bietet seinen Kunden zudem eine spezielle Software an, die die Windows-XP-Automaten unangreifbar gegen Schadsoftware von außen machen soll, wie der Sprecher sagt."
Die installieren dann einfach eine "Personal Firewall" drauf. SCNR ....
Ach herrjeh, hängen die Bankomaten immer noch alle am ISDN oder so? Dann haben die eh de facto ein internes Netz.
Ansonsten "openvpn-Netz" drunter oder meinetwegen ssh+Portforwarding, anständige IP-Tables-Regeln und gut ists .... Klar, ist nicht ganz so trivial wie bei $FIREWALL_ZU_HAUSE und Updates im Feld muß man vorsehen (falls doch irgendwo ein Bug gefunden wird), aber auf so einem Ding läuft ja eh kaum was ...
Ab 10 Lizenzen ein Flasche snake oil gratis.
;-) Beim Kauf der 1 Lizenz ist die Flasche "Snake Oil" der Teststellung auch inbegriffen.
So jetzt hab ich auch obigen Link gelesen: Das stinkt mir nach einer Sales-Propaganda-Aktion der 3 großen Bankomat-Hersteller, damit "die Banken" (oder wer auch immer) da Extra-Geld in die Hand nimmt - entweder neue Software oder gleich neue Hardware+Software. Dafür wird auch das Dumm-Argument "Nach Supportende von M$FT Absturz" mibraucht .....
Die nächste Frage - auf anderer Ebene - ist ja auch, ob nicht eher die Bankomathersteller bzw. -betreiber zu 100% unter Zugzwang sind, wenn deren Lieferant etwas abkündigt (udn das schon vor vielen Jahren .....). Den Extraaufwand würden wohl alle gerne auf die eigenen Kunden abwälzen. Oder wenigstens die öffentliche Meinung der "Schuld" für die Verzögerung irgendwelcher Umstellungen.
Naja, bei Gelegenheit mit Leuten ratschen, die bei Banken arbeiten;-)
Bernd
grade gesehen: http://thehackernews.com/2014/03/indian-banks-switching-to-linux-rather.html
On 21/03/14 12:35, Bernd Petrovitsch wrote:
Die Bankomaten haben ja nichts mit den Banken zu tun - die waren aus historischen Gründen (war wohl etws Platz vonnöten und die Bargeldmengen dort drin sind auch nicht so klein) dort montiert, aber jetzt stehen auch welche in Supermärktme rum -, sondern werden von Europay IIRC "betrieben". Hmm, die heißen jetzt wohl https://www.paylife.at/ (weil http://www.eurppay.at/ dorthin redirected) ...
Jein, die Bankomaten in Banken haben meistens andere Betreiber als die die auf die Straße zeigen. Aber im Endeffekt sinds wieder nur ein paar wenige Anbieter.
Und wie die das alles designen und bauen bzw. bauen lassen ....
"Denn nun muss jedes Haus einen Wartungsvertrag mit Microsoft abschließen, wenn es keinen Systemabsturz bei der Geldausgabe riskieren will."
*muss*?! Ich krieg' halt keine Updates mehr. Am Desktop von $SEKRETÄRIN ist das (hoffentlich) egal, halt mit Treibern wird es bei neuer Hardware immer mühsamer. Ist sowieso Techie-Schrott, was die da schreiben ...
So strategisch hätte man sich schon vor Jahren (weil XP ist schon vor Ewigkeiten zum 1. Mal abgekündigt worden) überlegen können:
- Läuft die Bankomat-User-Interface-Applikation "as is" unter Wine?
- Wie mühsam ist das portieren/umschreiben auf $XXX (und das $XXX könnte etwas sein, daß es vllt. nicht nur bei Monopolisten gibt). Und wenn es PHP oder TK oder perl ist (oder meinetwegen Java) - soooo super-toll oder gar ressourcenfressend ist das Bankomat-UI auch nicht, daß man das dafür ganz nah am Graphik-Subsystem und Widget-Set schreiben muß. Das könnte man auch als JavaScript bauen ....
Und dann kann man die alte Hardware vermutlich noch Jahrzehte weiterbetreiben ....
Sofern sich technisch nichts an den Karten ändert, bzw das alles einfach updatebar ist.
lg, Florian
Ahoy hoy,
Ich finde mich ungern in der Situation wieder, die Banken hier zu verteidigen, aber ich glaube ganz ehrlich, dass die Situation weit nicht so einfach ist, wie sie hier dargestellt wird.
Der Artikel strotzt etwas von Bullshit, aber grundsätzlich stellt sich doch die Frage ob Banken nicht mal eine echte IT-Strategie machen sollten, statt das Mizitant-Betriebsystem auf ihre Hardware zu frickeln.
Ich glaube, dass man als Bank relativ wenig Auswahl hat, welches Softwaresetup man auf seinen Bankomaten einsetzt.
Die Bankomaten haben ja nichts mit den Banken zu tun - die waren aus historischen Gründen (war wohl etws Platz vonnöten und die Bargeldmengen dort drin sind auch nicht so klein) dort montiert, aber jetzt stehen auch welche in Supermärktme rum -, sondern werden von Europay IIRC "betrieben". Hmm, die heißen jetzt wohl https://www.paylife.at/ (weil g http://www.eurppay.at/ dorthin redirected)
"1993 werden beide Gesellschaften zur Europay Austria Zahlungsverkehrssysteme GmbH und deren Processing-Tochter Austrian Payment Systems Services (APSS) fusioniert. Am 1. September 2007 wurde Europay Austria in PayLife Bank GmbH umbenannt."[0]
Und wie die das alles designen und bauen bzw. bauen lassen ....
Jein, die Bankomaten in Banken haben meistens andere Betreiber als die die auf die Straße zeigen. Aber im Endeffekt sinds wieder nur ein paar wenige Anbieter.
Das stimmt zwar grundsätzlich, aber trotzdem wickelt Paylife alle Transaktionen ab, die zwischen unterschiedlichen Banken stattfinden. Wenn du also mit deiner $BANK Bankomatkarte bei einem $OTHER_BANK Bankomat abhebst, baut dieser Bankomat eine Verbindung zu den Paylifeservers auf, der wiederum versucht, den Host deiner Heimatbank zu kontaktieren - vereinfacht dargestellt. Und diese Kommunikation läuft über irgendwelche proprietären Pseudoindustriestandards, die nicht einfach so mir nichts dir nichts mal selbst implementiert werden können.
So strategisch hätte man sich schon vor Jahren (weil XP ist schon vor Ewigkeiten zum 1. Mal abgekündigt worden) überlegen können:
- Läuft die Bankomat-User-Interface-Applikation "as is" unter Wine?
Wie gesagt, das UI ist - denke ich - hier wirklich nicht der entscheidende Faktor, sondern eher der proprietäre Protokollstack zur Kommunikation mit Paylife und anderen Banken. Und ich bin mir ziemlich sicher, dass die Supportverträge mit den Softwarelieferanten eine Ausführung unter Wine auf die eine oder andere Art ausschließen.
- Wie mühsam ist das portieren/umschreiben auf $XXX (und das $XXX könnte etwas sein, daß es vllt. nicht nur bei Monopolisten gibt). Und wenn es PHP oder TK oder perl ist (oder meinetwegen Java) - soooo super-toll oder gar ressourcenfressend ist das Bankomat-UI auch nicht, daß man das dafür ganz nah am Graphik-Subsystem und Widget-Set schreiben muß. Das könnte man auch als JavaScript bauen ....
Und dann kann man die alte Hardware vermutlich noch Jahrzehte weiterbetreiben ....
Erneut: Die UI ist sicher nicht das Problem, sondern die proprietären Protokolle.
"Wincor Nixdorf bietet seinen Kunden zudem eine spezielle Software an, die die Windows-XP-Automaten unangreifbar gegen Schadsoftware von außen machen soll, wie der Sprecher sagt."
Die installieren dann einfach eine "Personal Firewall" drauf. SCNR ....
Ich glaube, dass es hier eher um eine Application Whitelisting Lösung geht - was vermutlich eine der günstigeren halbwegs sinnvollen Lösungen ist, abhängig vom eingesetzten Produkt.
Ach herrjeh, hängen die Bankomaten immer noch alle am ISDN oder so? Dann haben die eh de facto ein internes Netz.
»Denn anders als in den USA oder Großbritannien sind deutsche Geldautomaten nicht mit dem Internet verbunden […]«[1] Das gilt meines Wissens nach auch für österreichische Bankomaten.
Also so unkompliziert ist die Situation wohl leider nicht. Ich halte einen Umstieg auf Linux und freie Software in solchen Bereichen für absolut sinnvoll und technisch machbar - aber eine einzelne Bank kann das nicht einfach so mir nichts dir nichts machen, das müsste die gesamte Industrie tun. Und das halte ich für etwa so unrealistisch wie dass die zOS Hosts in naher Zukunft durch OpenBSD ersetzt werden.
Gruß, Simon
Hi!
On Son, 2014-03-23 at 12:28 +0100, Simon Hornbachner wrote: [...]
Ich finde mich ungern in der Situation wieder, die Banken hier zu verteidigen, aber ich glaube ganz ehrlich, dass die Situation weit nicht so einfach ist, wie sie hier dargestellt wird.
Der Artikel strotzt etwas von Bullshit, aber grundsätzlich stellt sich doch die Frage ob Banken nicht mal eine echte IT-Strategie machen sollten, statt das Mizitant-Betriebsystem auf ihre Hardware zu frickeln.
Ich glaube, dass man als Bank relativ wenig Auswahl hat, welches Softwaresetup man auf seinen Bankomaten einsetzt.
In der Praxis wohl ja. Andererseits könnte die Bank/Paylife/... da vom Lieferanten auch etwas fordern (der natürlich Extra-Wünsche zu Extra-Geld macht). Realistischerweise werden da ahnungslose Sales-Leute mit allg. Blafasel "supportetes OS ...." u.ä. unterwegs sein und v.a. nicht 20 Jahre in die Zukunft denken (sondern eher "was haben wir fertig?").
[...]
Und wie die das alles designen und bauen bzw. bauen lassen ....
Jein, die Bankomaten in Banken haben meistens andere Betreiber als die die auf die Straße zeigen. Aber im Endeffekt sinds wieder nur ein paar wenige Anbieter.
Das stimmt zwar grundsätzlich, aber trotzdem wickelt Paylife alle Transaktionen ab, die zwischen unterschiedlichen Banken stattfinden. Wenn du also mit deiner $BANK Bankomatkarte bei einem $OTHER_BANK Bankomat abhebst, baut dieser Bankomat eine Verbindung zu den Paylifeservers auf, der wiederum versucht, den Host deiner Heimatbank zu kontaktieren - vereinfacht dargestellt. Und diese Kommunikation läuft über irgendwelche proprietären Pseudoindustriestandards, die nicht einfach so mir nichts dir nichts mal selbst implementiert werden können.
So strategisch hätte man sich schon vor Jahren (weil XP ist schon vor Ewigkeiten zum 1. Mal abgekündigt worden) überlegen können:
- Läuft die Bankomat-User-Interface-Applikation "as is" unter Wine?
Wie gesagt, das UI ist - denke ich - hier wirklich nicht der entscheidende Faktor, sondern eher der proprietäre Protokollstack zur Kommunikation mit Paylife und anderen Banken. Und ich bin mir ziemlich
Derartiges ist idR auch portierbar, wenn man will. Klar, da mußt halt wieder testen etc. - und u.U. tauchen die Leichen aus dem Keller auf;-)
sicher, dass die Supportverträge mit den Softwarelieferanten eine Ausführung unter Wine auf die eine oder andere Art ausschließen.
Mit "XP ist tot" wird man Druck machen können, wenn man will, und eine "liberalere" Interpretation finden können. Mitunter finden sich kommerzielle Supporter für $LINUX_DISTRI und $WINE ....
Die Kunst ist da eher, die Player dort zu kennen und deren Positionen/Abhängigkeiten/Interessen/..., damit "man" den richtigen die richtigen Argumente reichen kann. Und mit "Player" sind i.Ü. (immer;-) auch die firmen-internen Stakeholder da und dort gemeint - wenn der IT-Chef (oder Subchef oder Abt.-Leiter) alle 2 Jahre auf eine M$FT-Fortbildung nach Redmond auf M$FTs Kosten fährt (die eh sein Arbeitgeber übern Supportvertrag zahlt), wird der nie umstellen .....
- Wie mühsam ist das portieren/umschreiben auf $XXX (und das $XXX könnte etwas sein, daß es vllt. nicht nur bei Monopolisten gibt). Und wenn es PHP oder TK oder perl ist (oder meinetwegen Java) - soooo super-toll oder gar ressourcenfressend ist das Bankomat-UI auch nicht, daß man das dafür ganz nah am Graphik-Subsystem und Widget-Set schreiben muß. Das könnte man auch als JavaScript bauen ....
Und dann kann man die alte Hardware vermutlich noch Jahrzehte weiterbetreiben ....
Erneut: Die UI ist sicher nicht das Problem, sondern die proprietären Protokolle.
Das gehört ja eh alles dazu - auch je nachdem wo das läuft ...
Der Hersteller der gesamten Applikation/Stacks/... muß natürlich mitziehen - und bei jeder Art von Migration. Von XP auf Win7 gibt es halt das "läuft 1:1"-Versprechen von M$FT als Ausrede ....
"Wincor Nixdorf bietet seinen Kunden zudem eine spezielle Software an, die die Windows-XP-Automaten unangreifbar gegen Schadsoftware von außen machen soll, wie der Sprecher sagt."
Die installieren dann einfach eine "Personal Firewall" drauf. SCNR ....
Ich glaube, dass es hier eher um eine Application Whitelisting Lösung geht - was vermutlich eine der günstigeren halbwegs sinnvollen Lösungen ist, abhängig vom eingesetzten Produkt.
Das ist das große Problem, daß halt wir nur annehmen können und glauben müssen - schon deshalb ist das Thema so als solches nur auf "Krone"-Niveau diskutierbar ....
Nur kann man das System (was läuft wo und wie) im Detail nicht öffentlich diskutieren, weil - aus Sicherheitsgründen - das geheim gehalten werden muß, weil sonst ja jeder das Hacken kann .... /sarcasm-off
MfG, Bernd
fellowship-austria@lists.fsfe.org