BuFaTa ET Wiki

Das Wiki der Bundesfachschaftentagung Elektrotechnik

Benutzer-Werkzeuge

Webseiten-Werkzeuge


arbeitskreise:technikfolgenabschaetzung:protokoll_muenchen2017

Protokoll Technik Folgenabschätzung

Anwesend: Robert Helling (Gast, µc³), Christina Gürster (Alumnus, TH Regensburg), Robert Niebsch (Alumnus, TU Dresden), Nils (RWTH Aachen), Paul Geisler (HS Ostfalia), Alexander Greinert (HS Ostfalia), Pascal Lange (HS Ostfalia), Matthias Gleiminger (HTW Berlin), Tobias (Uni Paderborn), Isabel (Uni Paderborn), Henrik (Uni Paderborn), Christian(Uni Paderborn), Moses (TU Wien), Peter Hartebrodt (HTW Dresden), Alexander Deublein (FAU Erlangen-Nürnberg), Julian Neureuther (FAU Erlangen-Nürnberg), Valentin Olpp (FAU Erlangen-Nürnberg), Richard (Universität Freiburg), Marc Kreft (FH-OWL), Josef Gartner (TU Dresden), Franz Schmidt (TU Dresden), Robert Lehmann (TU Dresden), Ludwig Tesar (TU Dresden), Arne Dubenhorst (TU Braunschweig)

Es soll um IoT Aspekte gehen. Spezielle technische Fragen, sollen nicht im Vordergrund stehen. Robert (µc³) gibt einen kurzen Impulsvortrag:

  • IoT wird kommen
  • jeder will alles Steuern und Überwachen können, dahingestellt ob sinnvoll
  • Hardware extrem günstig, aber auch langlebig?
  • „alle Geräte mit Elektroanschluss werden eine IP Adresse haben“
  • IBM Studie: minimale Software Fehler Quote = 1 Fehler pro 10000 Zeilen Code
  • Einfallstor für Hacker über diese Fehler z.B. Telekom Router, DNS-Server
  • Update Politik für viel IoT Hardware sehr mangelhaft
    • was kann man da machen?
    • Kunde fühlt sich nicht verantwortlich für mangelhafte Produkte und ist in der Regel nicht betroffen von den Angriffen seiner Geräte
  • Für die Kunden der möglicherweise magelhaften Produkte sind die Fehler in der Software der Produkte nicht entscheident. Die Leittrageden würden eher große Unternehmen sein, oder Organisationen, bei den es sich lohnt Internetangriffe durchzuführen.
  • Bei der nächsten Lücke werden wohl Politiker aktiv werden und in Aktionismus verfallen
    • was könnte dort kommen?
      • Registrierungspflicht, Regulierung, Zertifizierungspflicht
      • Produkthaftung für Software
        • Zur Zeit können die Softwarelieferanten / weisen Softwarelieferanten jegliche Schuld in den AGBs von sich zurück
      • Jetzt ist die Zeit noch auf die „Politik“ Einfluss zu nehmen.
      • Eine Möglichkeit wäre die verpflichtende Angabe eines „Verfallsdatum“ für elektronische Geräte, z.B. Garantierte Updates bis in 2/5/10/20 Jahren

Beginn der Diskussion dazu:

  • Ablaufdatum für viele Käufer vielleicht ignorierbar
    • Vorschlag: Zwangsabschaltung
    • Ablaufdatumsverlängerung durch Erkaufen von Support vom Händler oder Hersteller
  • Garantieverlängerung meist über Versicherung, Regelung über den Markt
    • Vorschlag: Hersteller gesetzlich zu Updates verpflichten
  • Regulierung wohl nur über den Verkauf realistisch. Ein Bestehen auf Fehlerfreiheit ist jedoch weltfremd. Updates sollten aber definitv erwartbar und in sinnvoller Weise vorgeschrieben werden, falls Fehler bekannt werden
  • Vorschlag: Möglicherweise sollten Geräte erst anfangen zu Arbeiten, wenn der Benutzer eine „Grundeinrichtung“ (Systempasswort) vorgenommen hat.
  • Denkbares Problem: „Updates“ ohne Fehlerbehebung/Sicherheitspatches – nur Versionsnummer erhöhen
  • Was ist bei „Open Source“ Projekten?
    • polemisch: was ist überhaupt „Open Source“? → Nichts ist nicht-kommerziell
  • offenes Hardwaredesign als Chance und Gefahr
    • beliebige Software drauf spielbar
    • Ausrede für Hersteller, Support einzustellen
  • Normierung und Zertifizierung von Software:
    • z.B. um wirklich grobe Fehler zu vermeiden
    • Wie soll die Zertifizierung aussehen?
    • Was soll diese Zertifizierung finden?
    • Aufwand problematisch/unrealistisch, da jedes Update zertifiziert werden müsste
    • Zertifizierung von Prozessen, nicht Patches
      • Welche Kriterien?
      • z.B. ISO 9001
  • Hürden für User bei Erstinbetriebnahme, z.B. Zwangs-Passwortänderung
    • oder auch: Koppelung mit Home-Devices
  • Anleitungen sind zu umfangreich
    • Problembehebungstechnisch sind teils nicht ausgerichtet genug, zu viele „Standart Sicherheitshinweise
    1. → Kunden haben keine Lust / Zeit diese komplett zu lesen
    • Anleitung wird erst interessant, wenn es wirklich Probleme gibt
    • Anleitungen sollten gesammelt im Internet zu finden sein
      • Es gibt z.T. kommerzielle Firmen, die dies anbieten (Alte Anleitunge einscannen und zur Verfügung stellen gegen Bezahlung)
  • Allerdings: Von geschätzten 60Mio. Konsumenten in Deutschland kontaktiert in akuten Phasen nur ein sehr kleiner Teil den Support –> Man kann davon ausgehen, dass der Großteil der Geräte läuft und ein Großteil der Kunden Anleitungen liest.
  • Internationales Problem - Problemlösungen mindestens auf EU-Ebene

Fachpolitiker haben bereits das Gespräch aufgenommen.

  • Standartisierung von Protokollen, an Stelle von Zertifikaten oder Prozessen
    • ISO für Home Automation
  • Hardware Security
    • z.B. elektronische Schlüssel
    • Hardware irgendwann nicht mehr in der Lage, die Sicherheit gewährleisten zu können
    1. > z.T. kein Problem, da Hardware so billig und somit einfach austauschbar
  • Über die KFZ Elektronik wurde sich nicht wirklich unterhalten, dabei handelt es sich noch wieder um ein ganz anderes Thema.
    • Softwareentwicklung ist bei Sicherheitsrelevanten Softwarekomponenten stärker getestet, dokumentiert.
      • Zertifizierungsprozesse sind möglicherweise zu lang?
    • Bei immer mehr Unterhaltungselektronik im KFZ wird die Sicherheit immer schwieriger zu kontrolieren sein.
  • Trade-Off auch hier natürlich zwischen Sicherheit, Schnelligkeit, Featuremenge
  • Wie kann ich diese Anforderungen von 08/15-Geräten erwarten, wenn nichtmal High-End Geräte das schaffen? – Schlichtweg notwendig!
  • Bsp. Krankenhaus oder auch Mestechnik-Geräte, für 50 000 € und mehr, deren Software irgendwann verfällt [da Basis z. B. ein veraltetes Windows-System])
  • Was bedeutet das für den Massenmarkt? Sind die Endkunden bereit, plötzlich die damit verbundenen Kosten auch zu tragen?
  • Ansätze:
    • Firmen in Zukunft verpflichten, dort besser zu werden
    • alte Geräte in z.B. „isolierte“ Netze verpacken

Besuch der CCC-Räumlichkeiten in München

Zusammenfassung

  • Es gab sehr viel Brainstorming. Eine gezieltere Befassung mit einzelnen Themen könnte noch sinnvoll sein.
    • Mehr strukturiert,
    • Zielsetzung?:
    • Strategien ausarbeiten?
  • Letztendlich ist unser Spielraum technische Belange betreffend allerdings begrenzt. (Werden keine Normen schaffen können etc.)
  • Wir könnten uns allerdings politisch äußern, um die Diskussion in eine für uns interessante und relevante Richtung zu lenken.
    • (Stellungnahme?)
  • Nicht behandelt: Besprechen, wie Hochschulen damit umgehen, solche Problematiken auch zu Lehren oder forschend zu behandeln.
    • →Welche Fächer oder Vorlesungen bieten die unterschiedlichen Hochschulen oder Universitäten für diese Themen an?

Ende

Beginn: 09:15 Uhr
Ende: 12:00 Uhr
Der AK ist nicht fertig und sollte auf weiteren Tagungen besprochen werden. Zwischenplenum: Können sich Hochschulen oder Universitäten dazu äußern, ob sie sich an ihren Standorten zu diesen Themen in Vorlesungen oder Praktika mit diesem Thema beschäftigt wird?



Die hier im BuFaTa ET Wiki dargestellten Arbeitsdokumente sind Einzelbeiträge der jeweiligen Autoren und i.d.R. nicht repräsentativ für die BuFaTa ET als Organisation. Veröffentlichte Beschlüsse und Stellungnahmen der BuFaTa ET befinden sich ausschließlich auf der offiziellen Homepage.
arbeitskreise/technikfolgenabschaetzung/protokoll_muenchen2017.txt · Zuletzt geändert: 22.02.2018 20:17 von Robert Niebsch