http://www.dasgelbeforum.net/forum_entry.php?id=435391

kennst Du schon die Firma Proteus?
Die stellen Pillen her mit eingebautem Chip. Das heißt, man verordnet Chips zur oralen Einnahme. Das 1mm² große Mini-Labor wandert durch den Körper, misst Herzfrequenz, Körperlage, Aktivität des Patienten und Medikamentenkonzentration (und wer weiß was noch alles), sendet die Daten an ein Pflaster und das sendet eine Info an ein Smartphone oder gleich zum Arzt... der Körper des Menschen ans Web angeschlossen...

Die Wearables sind dagegen ja echt noch primitiv, man kann sie einfach ausziehen, bzw. man kann denjenigen ausziehen, der so was trägt:

Nein, es wird sogar noch weiter gehen: mit
Wearables

Ärzteblatt und Co sehen eine wunderbare Zukunft...
https://www.aerzteblatt.de/nachrichten/51182/Elektronische-Pillen-Nachrichten-an-das-Sm...
http://www.apotheke-adhoc.de/nachrichten/nachricht-detail/pillen-mit-mikrochips/?t=1
https://deutsche-wirtschafts-nachrichten.de/2013/10/31/menschen-koennen-ueber-chips-in-...

Und dann gibt es noch Chips, die der Arzt (oder sonstwer?) fernsteuern kann um Medikamente in den Körper zu geben:
http://www.zeit.de/2012/10/M-Chipmedizin

Was die sich noch so alles einfallen lassen...

Ich ess lieber ein paar Lindenblätter zum Frühstück...

Viele Grüße
Konstantin

Noch lachst Du, lieber Literaturhinweis, aber wenn hier wirklich mal für ne Woche die Lichter ausgehen und die Leute im Supermarkt kein Futter mehr kriegen, dann wird das Ganze nicht sehr lustig werden.

Kein Grund, darum mit dem Lachen aufzuhören. Es kommt, wie es kommt und ich weiß das schon seit Jahrzehnten.

Da reicht es dann nicht mehr, ein paar Vorräte gebunkert zu haben, ..., wenn die hungrigen Horden marodierend durch die Straßen ziehen.

Je hungriger, desto matter, darum meine vielen Anregungen zu dem Thema.

man muss sie auch verteidigen können

Ebenfalls - hier entlang. Oder für Individualisten.

Oder Fatalisten.

Die meisten werden das aber erst lesen wollen, wenn sie es nicht mehr lesen können.

kleine Randbemerkung zu einem untergordneten Aspekt Deines Beitrags:

[...] - auch in Banken und Versicherungen laufen z. T. noch Großrechneranwendungen,

bei der Großbank, für die ich bis vor fünf Jahren als Anwendungsentwickler tätig war, bildet der Mainframe nach wie vor das Rückgrat der IT, ohne ihn liefe in dem Laden überhaupt nichts. Die Großrechner-Hardware ist auf dem neuesten Stand und die hochkomplexe, für ein kleines Licht wie mich nicht überschaubare Software-Landschaft (zumeist in COBOL programmiert) wird von hunderten von Entwicklern gewartet und permanent weiterentwickelt.

Ja, nur, daß solche Organisationen immer mehr ins Hintertreffen geraten, was modernere Programmiersprachen und objektorientiertes Programmieren betrifft. Auch Ericssons Telefonvermittlung läuft auf Milliarden Zeilen "strukturiert programmiertem" Spaghetti-Code.

Seit der NATO-Softwarekrisenkonferenz 1968 weiß man aber, daß das eine gefährliche Sackgasse werden kann. Daß man dann stattddessen ADA aus der Taufe hebt, ist dem geschuldet, was der legendäre Dijkstra über COBOL sagte: "A camel is a horse designed by a committee".

So sieht es, soweit mir bekannt, bei allen großen Banken aus.

Nein, diejenigen, die auf SAP (R/3 bzw. HANA)-Banking umgestellt haben (oder IS Insurance), sind schon längst auf Client-Server - vgl. Postbank.

An der Expertise würde eine Umstellung auf Client-Server-Systeme wohl nicht scheitern angesichts der Heerscharen von COBOL-Entwicklern, Datenbank- und System-Admins, die sich bei den Banken tummeln und von denen einige sogar unter siebzig Jahre alt sind ; ich vermute in erster Linie Kostengründe (eine solche Aktion würde Unsummen verschlingen), vor allem aber Sicherheitsaspekte, die einem Systemwechsel im Wege stehen.

Es ist von Institution zu Institution ganz unterschiedlich.

So kenne ich z.B. eine Großbank, die noch 16 Jahre nach offiziellem Wartungsschluß SIEMENS BS1000 auf ihren Rechnern hatte. Als nun Siemens seinerseits die BS1000-erfahrenen Entwickler wegstarben, wurde es brenzlig und sie bekamen die Pistole auf die Brust gesetzt. Man migrierte dann nolens volens auf BS2000. Mit dem EDT wurden auch schon mal die Kontoauszüge erstellt, wenn die hierarchische Datenbank mal wieder nicht so ganz in der Übergangsphase mit der neueren relationalen Version UDS harmonieren wollte.

Auch der einstige Großrechner-Hersteller Siemens machte schon 1996 die Kehrtwende: SIEMENS TO PHASE OUT MAINFRAMES: BS2000 ON R4400. (Das BS3000 war übrigens kein Nachfolger von BS2000, sondern ein Fujitsu-OS.)

Ein ordentlich administrierter z/OS Mainframe ist von außen nicht hackbar

Auch hier ein kleiner Einspruch: die ersten Hacker, die diesen Namen überhaupt begründet haben, waren Jungs, aus meist gutem Hause, die sich in große Rechenanlagen, zuvörderst ihrer eigenen Universitäten, aber auch in andere Unternehmens-Rechenzentren "eingehackt" haben, um sich "Zeitscheiben" aus dem Time-Sharing-Betriebssystem zu 'klauen', da damals (in den sechziger und siebziger Jahren) keiner über einen Computer verfügen konnte, weil es diese Tischgeräte in größerem Umfange erst seit Anfang der achtziger Jahre gab.

Die zweite Zielscheibe der Hacker waren die Telefonanlagen von ATT und den "Baby-Bells", d.h. sie manipulierten mit Modems in Telefonzellen usw. die Systeme so, daß sie kostenlose Fern- und Auslandsgespräche führen konnten. Einer schaffte es gar, eine offiziell nicht existierende Brücke zwischen dem Telefon- und dem Fernschreibernetz ausfindig zu machen. Und als Krönung und Königsdisziplin galt dann, diese beiden Disziplinen zu vereinen und Rechenleistung der Großrechner über kostenlose Telefon-Datenleitungen nach außen zur Verfügung zu stellen (z.B. über Teletype).

Daß dieses Gebiet derzeit komplett verwaist ist, hat m.E. lediglich damit zu tun, daß der Antrieb, Rechenleistung "zu klauen" weggefallen ist, seit jedes Kind die Rechenleistung mehrerer Großrechenzentren der siebziger Jahre auf seinem Hausaufgabentisch stehen hat und so auch jeder 'Hacker'.

Siehe auch Hacking History – A Timeline Of Hack Tactics [Infographic].

Diese Anfangsgründe sind mit u.a. überraschenden Reminiszenzen, z.B. in Büchern beschrieben wie:

- Hackers: Heroes of the computer revolution

- Underground: Die Geschichte der frühen Hacker-Elite

- Dreiundzwanzig - 23 - Die Geschichte des Hackers Karl Koch

- Kleine Kulturgeschichte des Hackens

- On the Way to the Web: The Secret History of the Internet and Its Founders

- Nerd Attack!: Eine Geschichte der digitalen Welt vom C64 bis zu Twitter und Facebook

In beiden Fällen müht man sich seit Jahren, auf Client-Server zu migrieren, mit durchwachsenem Erfolg ...

Tja, das ist so eine Sache. SAP hat es relativ problemlos damals geschafft, von SAP R/2 (Mainframe) auf R/3 (Client-Server) umzustellen. Kann man meiner Erinnerung nach in "SAP, die heimliche Software-Macht" nachlesen. Jedenfalls lief das so: man portierte den R/2-ABAP-Code auf IBM-Rechner und stellte sie auf der Systems in München oder der CeBit auf (weiß ich nicht mehr). Es lief fast auf Anhieb. Da aber die Kunden, die ja alle nur R/2 kannten, auf der Messe nicht glauben wollten, daß das auf den kleinen IBM-Workstations "performant" läuft, legten die Messe-Betreuer von SAP noch ein dickes Kabel vom Tisch mit den IBM-Rechnern nach hinten und sagten, das sei "die Standleitung nach Walldorf", denn es bestand die Gefahr, daß die Manframe-gewöhnten Kunden den Eindruck bekommen könnten, SAP sei keine ernstzunehmende Unternehmenssoftware.

Das hat SAP vor allem diesem Mann zu verdanken, der jahrelang mit darauf bestand, daß ABAP wurde, was es ist und sich auf keine externen Experimente einließ (anfangs war es noch der "Allgemeine Berichts-Aufbereitungs-Prozessor" (anfänglich ähnlich IBM RPG).

Wie die Zeiten sich geändert haben ...

Aber mit dem brauch ich da gar keine Diskussion anzufangen, er hat ja nichts zu verbergen, wissenschon.

Noch lachst Du, lieber Literaturhinweis, aber wenn hier wirklich mal für ne Woche die Lichter ausgehen und die Leute im Supermarkt kein Futter mehr kriegen, dann wird das Ganze nicht sehr lustig werden. Da reicht es dann nicht mehr, ein paar Vorräte gebunkert zu haben, man muss sie auch verteidigen können, wenn die hungrigen Horden marodierend durch die Straßen ziehen.

Ach Dreck, ich wollte mir doch heute nicht die Laune verderben lassen.

kleine Randbemerkung zu einem untergordneten Aspekt Deines Beitrags:

[...] - auch in Banken und Versicherungen laufen
z. T. noch Großrechneranwendungen,

Für Versicherungen kann ich nicht sprechen, aber bei der Großbank, für die ich bis vor fünf Jahren als Anwendungsentwickler tätig war, bildet der Mainframe nach wie vor das Rückgrat der IT, ohne ihn liefe in dem Laden überhaupt nichts. Die Großrechner-Hardware ist auf dem neuesten Stand und die hochkomplexe, für ein kleines Licht wie mich nicht überschaubare Software-Landschaft (zumeist in COBOL programmiert) wird von hunderten von Entwicklern gewartet und permanent weiterentwickelt. So sieht es, soweit mir bekannt, bei allen großen Banken aus.

[...] weil man die Zeit scheut und die Expertise nicht mehr hat, sie auf
Client-Server zu portieren).

An der Expertise würde eine Umstellung auf Client-Server-Systeme wohl nicht scheitern angesichts der Heerscharen von COBOL-Entwicklern, Datenbank- und System-Admins, die sich bei den Banken tummeln und von denen einige sogar unter siebzig Jahre alt sind ; ich vermute in erster Linie Kostengründe (eine solche Aktion würde Unsummen verschlingen), vor allem aber Sicherheitsaspekte, die einem Systemwechsel im Wege stehen. Ein ordentlich administrierter z/OS Mainframe ist von außen nicht hackbar (nur eine Ausnahme bestätigt die Regel), lediglich interne Mitarbeiter hätten eine gewisse Chance, Schaden anzurichten. Und die Sicherheit steht bei den Banken - gleich nach dem Profit - ganz oben auf der Prio-Liste.

Von den Banken abgesehen kenne ich noch einen namhaften PayTV-Sender und ein mittelständisches Autohaus, deren IT zu mehr oder weniger wesentlichen Teilen auf Großrechnersystemen basiert. In beiden Fällen müht man sich seit Jahren, auf Client-Server zu migrieren, mit durchwachsenem Erfolg...

Besten Gruß,

Nordlicht

PS: Falls ich eine Methode finde, einen Schnappschuß des Gundstücks hier
einzustellen, werde ich es tun. Vielleicht erkennt sich jemand wieder?

PS: Falls ich eine Methode finde, einen Schnappschuß des Gundstücks hier einzustellen, werde ich es tun. Vielleicht erkennt sich jemand wieder?

Was einmal als scheinbare Erleichterung des Lebens in die Welt kam, blieb auch - zumindest solange, wie es nicht durch 'noch etwas besseres' abgelöst wurde.

Und selbst das mit dem Ablösen ist so eine Sache - haufenweise laufen in allen möglichen Anwendungen noch Rechnersysteme aus den sechziger und siebziger Jahren - bei der NASA, dem US-Militär, in Industrieanlagen, bei Fluggesellschaften usw. Teilweise muß man Rentner reaktivieren, wenn was schief geht; man kauft panisch alte gebrauchte Anlagen gleicher Bauart vom Schrott, um ja Ersatzteile bei der Hand zu haben.

Viele benutzen ja auch noch Windows XP, und innerhalb dessen oft auch noch DOS-Routinen (nicht, daß XP schlecht wäre, sonst hätten diese Leute sich ja ein Upgrade gegönnt - es hat aber meist damit zu tun, daß darunter Hardware und Software läuft, die man eben gerade nicht ohne hohen Aufwand erneuern kann, vgl. die Geldautomaten, von denen viele noch mit XP arbeiten und für die extra die Wartung verlängert wurde - auch in Banken und Versicherungen laufen z.T. noch Großrechneranwendungen, weil man die Zeit scheut und die Expertise nicht mehr hat, sie auf Client-Server zu portieren).

Nicht kaufen, nicht installieren,

Wenn also jetzt mal ein Alexa oder so was ins Kinderzimmer Einzug gehalten hat, dann wird das Ding auch weiterlaufen.

Ebenso eine Überwachungskamera und andere Dinge, wie ein IoT-Toaster werden auch nur dann ausgetauscht, wenn sie physisch kaputt sind.

wo immer möglich meiden oder aktiv zerstören

Ich kann doch nicht beim Nachbarn einbrechen und dessen Kühlschrank sabotieren???

Nein, es wird sogar noch weiter gehen: mit Wearables z.B.

Das fängt schon mit irgendwelchen Fitness-Aufzeichnungsgeräten an, die mit dem Smartphone kommunizieren, und deren Ergebnisse dann auch noch brühwarm auf irgendwelchen Internetseiten peinlich genau mitprotokolliert werden, damit der künftige Schwiegervater auch genau nachlesen kann, ob der künftige Schwiegersohn nicht vielleicht beim ersten GV einen Herzkasper kriegt ...

Im Gegenteil: das einzige, was diesen Dingen weiträumig den Garaus macht, ist ein EMP-Schock, gefolgt von einem langdauernden Stromausfall.

Und, wie gerade geschrieben, diese IT- und IoT-Revolution frißt gerade ihre Kinder:

- The Real Story of Stuxnet

- An Unprecedented Look at Stuxnet, the World's First Digital Weapon

Dann die Vorbereitungen für Crash Override:

- Power grids at risk as Stuxnet successor emerges in Ukraine

Siehe die Dokumentation von ESET und Dragos und die zugehörige Studie: "CRASHOVERRIDE - Analyzing the Threat to Electric Grid Operations" (PDF, 35 Seiten).

Auch das US-CERT hat's schon geblickt, sieht aber nur ein "mittleres Risiko". Das ist verständlich, das US-Strommnetz bricht auch so immer mal wieder zusammen. Die USA trainieren halt solche Szenarien, während man in der EU irrigerweise meint, das Stromnetz stabilisieren zu müssen.

Und auch der "30 Jahre alte Diesel" wird nicht weit kommen:

a) Keine Tanksäulen mehr in Betrieb

und

b) an jeder Straßenkreuzung Autos, die just in dem Moment stehen geblieben sind, als der Strom ausfiel und der EMP zuschlug. Die holt auch kein Abschleppfahrzeug mehr ab, weil:

c) der EMP zuschlug

d) keine Tanksäule mehr in Betrieb und

e) an jeder Straßenkreuzung Autos ...

                            

https://www.welt.de/wirtschaft/webwelt/article165475249/Cyberwaffe-aus-Russland-bedroht...

Je mehr sich das IoT bis dahin verbreitet hat, desto grauenvoller wird der
Stromausfall werden. Dann geht nichts mehr, aber auch rein gar nichts.

Ich habe noch einen 30 Jahre alten Diesel. Der wird eventuell noch fahren,
wenn sich die Massen mit selbstfahrenden Autos mit Blasen an den Füßen
durch die Straßen schleppen " />

Lasst am besten die Finger davon. IoT wird genauso implodieren wie die dotcom-Blase und die Biotech-Blase.

Dumm nur, wenn man vom Vermieter oder Provider gezwungen wird, sich "Smart-Meter" oder ferngelenkte Rauchmelder in die Bude zu hängen.

Sorry, aber das musste raus.

Wie immer hinkt die Buchliteratur hinterher bzw. redet erstmal die daraus zu erschaffende schöne neue Welt herbei.

Hier daher mal eine Literaturempfehlung, die die sich am Horizont abzeichnende Sicherheits(lücken)landschaft nachzeichnet:

- Practical Internet of Things Security von Brian Russell und Drew Van Duren, beide Sicherheitsspezialisten bei Leidos (als Kindle Edition).

Auszug aus dem Inhaltsverzeichnis:

Chapter 1: A Brave New World 1
Defining the IoT 3
Cybersecurity versus IoT security and cyber-physical systems 5
Energy industry and smart grid 11
Connected vehicles and transportation 11
Manufacturing 11
Wearables 12
Implantables and medical devices 12
The IoT in the enterprise 13
The things in the IoT 17
Operating systems 20
IoT data collection, storage, and analytics 30
IoT integration platforms and solutions 30
The IoT of the future and the need to secure 31
The future – cognitive systems and the IoT

Chapter 2: Vulnerabilities, Attacks, and Countermeasures 33
Primer on threats, vulnerability, and risks (TVR) 34
The classic pillars of information assurance 34
Threats 36
Vulnerability 36
Risks 38
Primer on attacks and countermeasures 39
Common IoT attack types 39
Attack trees 41
Building an attack tree 42
Fault (failure) trees and CPS 46
Fault tree and attack tree differences 47
Merging fault and attack tree analysis 47
Example anatomy of a deadly cyber-physical attack 49
Today's IoT attacks 52
Attacks 53
Wireless reconnaissance and mapping 53
Security protocol attacks 54
Physical security attacks 54
Application security attacks 54
Lessons learned and systematic approaches 55

Chapter 5: Cryptographic Fundamentals for
IoT Security Engineering 131
Cryptography and its role in securing the IoT 132
Accounting and management 160
Summary of key management recommendations 161
Examining cryptographic controls for IoT protocols 162
Cryptographic controls built into IoT communication protocols 162
Cryptographic controls built into IoT messaging protocols 167
Future directions of the IoT and cryptography 169

Chapter 7: Mitigating IoT Privacy Concerns 199
Privacy challenges introduced by the IoT 200
Wearables 202
Smart homes 202
Metadata can leak private information also 202
Respect for user privacy 218

Chapter 9: Cloud Security for the IoT 253
Cloud services and the IoT 254
Customer intelligence and marketing 256
Information sharing 256
Examining IoT threats from a cloud perspective 257
Exploring cloud service provider IoT offerings 259
AWS IoT 259
Microsoft Azure IoT suite 264
Cisco Fog Computing 265
IBM Watson IoT platform 267
MQTT and REST interfaces 267

Chapter 10: IoT Incident Response 281
Threats both to safety and security 282
IoT system categorization 287
IoT incident response procedures 289
The cloud provider's role 290
IoT incident response team composition 291

Siehe auch die bereits früher zusammengetragenen Literaturhinweise zu verwandten Themen:

- Computersicherheit

- Datensicherheit/Datenschutz

- Robotik/Automatisierung

- Ratgeber Einbruchschutz