Pablo Endres – Geschäftsführer bei SevenShift GmbH
Lieber Pablo, kannst Du uns etwas zu Deinem Hintergrund und Deiner aktuellen Rolle erzählen?
Ich komme ursprünglich aus Venezuela, habe dort Informatik-Ingenieurwesen studiert. Hab als Kind auch 6 Jahre in Kanada gelebt. Seit 14 Jahren lebe und arbeite ich jetzt in Deutschland.
Als ich an der Uni war, habe ich nebenbei als Netzwerkadministrator gejobbt. 1998 wurden wir zum ersten Mal gehackt, und ich musste mich darum kümmern. Das war noch ein Bastion Server, Solaris 6 mit Telnet-Server und FTP-Server. Keine Verschlüsselung (SSH und die “Moderne-Protokolle” waren nagelneu). Das haben wir alles aufgeklärt. Seitdem bin ich in Security verliebt. Nach dem Studium habe ich dann bei einem Telekom-Unternehmen angefangen und kurz danach meiner erste Firma gegrundet.
Ich bin Gründer und Geschäftsführer von SevenShift, eine echte Boutique. Derzeit sind wir 5 Personen stark. Wir legen den Fokus auf IoT-Security – von Hardware, Firmware, Backends in der Cloud bis zu den Apps, einfach das gesamte IoT-Projekt. Wir bieten Pen Testing, Security-by-Design und Trainings. Am Liebsten werden wir am Anfang des Projekts miteinbezogen, um Security von Beginn an zu berücksichtigen. Ich kooperiere auch mit Justin Searle und seinem controlthings Team, um den ICS / OT Offensive Security Kurs z.B. auf Deutsch und Spanisch anzubieten (wir haben uns vor langer Zeit bei einer Black Hat Konferenz kennengelernt).
Wie sieht Dein typischer Arbeitsalltag aus?
Meistens fange ich damit an, zu schauen, wer vom Team was von mir braucht. Am Liebsten verbringe ich dann wirklich Zeit mit Kundenprojekten, beispielsweise zur Abstimmung von Anforderungen, Security-Reviews und Hardcore Security Testing. Ein paar Mal pro Jahr führen wir Trainings durch. Ich liebe es, zu unterrichten, das finde ich wirklich schön, wenn ich die Schulungen durchführen darf.
Zum Glück sind wirklich noch 70% Doing, und der Rest eben notwendige Abstimmung, Excel und Powerpoint und sowas.
Was sind aus Deiner Sicht interessante Trends bei OT und IOT-Security?
Es gibt eine große Bewegung hinsichtlich Normen, Standardisierung und Gesetzen, z.B. ETSI EN 303 645, das wird uns sicher helfen. Beispielsweise hat sich MQTT über TCP quasi als Standard etabliert. NBIOT und LoRaWAN sind mittlerweile fast in allen Projekten als Netzwerkprotokolle gesetzt.
Bei einigen Kunden sehen wir parallel zu IT und OT eine Art „Shadow-IoT“, beispielsweise Sensoren.
Kannst Du uns (ohne Namen zu nennen) einmal einen tatsächlich durchgeführten Pen-Test an einem IoT-Gerät oder einer vernetzten Anlage beschreiben?
OK, ich erzähle mal etwas von einem Projekt im Bereich SmartCity. Dabei haben wir mehrere Produkte von unterschiedlichen Herstellern bekommen und diese systematisch getestet.
Wie habt Ihr das strukturiert?
Wir haben die Standardphasen wie bei jedem Pen Test in der IT auch:
- Pre-Engagement Actions – Sehr wichtig bei OT, z.B. Site Surveys
- Reconnaissance
- Threat Modeling & Vulnerability Identification
- Exploitation
- Post-Exploitation
- Reporting
- Resolution & Re-Testing
Natürlich sind die Übergänge fließend.
Wie seid Ihr vorgegangen?
Wir hatten den Auftrag, mehrere SmartCity Lösungen zu analysieren. Unser Bericht wurde auch zur Produktauswahl durch den Endkunden herangezogen.
Als erstes mussten wir die Lösungen verstehen, Hardware bekommen und uns dann Zugriff verschaffen. Wir präferieren im Allgemeinen einen Whitebox Approach, da wir Zeit, Energie und natürlich das Geld des Kunden dann am besten einsetzen können.
Wir haben in ersten Schritten beispielsweise einfach die Dokumente reviewed und die normalen Nutzerinteraktionen in funktionalen Tests geprüft („Golden Paths“). Dabei haben wir dann mit Sniffen und Reverse Engineering angefangen. Parallel dazu sind klassische Tests auf dem Backend und den Apps erfolgt.
Welche wesentlichen Probleme habt Ihr letztendlich identifiziert?
Wir haben sehr viele Probleme entdeckt, die aus den OWASP Top 10 Listen bekannt sind. Also z.B.
- Klartext Credentials und Netzwerkkommunikation
- Fehler bei der Konfiguration von Authentifizierung und Autorisierung
- Injection bei backends, spoofing, etc.
- Im Prinzip waren alle getesteten Produkte unsicher, selbst die von professionellen Unternehmen.
Wie hat der Kunde Maßnahmen daraus priorisiert abgeleitet?
Wir mussten die Hersteller bei der Thematik sensibilisieren. Teilweise hat das Verständnis gefehlt, dass Sicherheitsmaßnahmen wirklich notwendig sind. Einige Hersteller dachten, sie brauchen keine Verschlüsselung, weil sie keine PII (personenbezogenen Daten) speichern oder verarbeiten.
Sobald die Probleme erkannt waren, konnten wir den Kunden helfen, die Sicherheit zu verbessern. Beispielsweise waren einige Maßnahmen:
- SSL Hardware Support war vorhanden, das wurde einfach angeschaltet
- Einführung eines sicheres Authentifizierungsverfahrens
- ACLs bei den Queues konfiguriert, um den Zugriff auf andere Geräte oder Backend-Bereiche zu unterbinden.
Was war in einem anderen Fall eine schwierige technische Herausforderung für Dich und Dein Team, und wie seid Ihr damit umgegangen?
Davon gibt es viele. Jedes Projekt hat seine eigenen Herausforderungen – aber das ist genau das, was mir Spaß macht. Wenn wir nur Standardprojekte hätten, wäre uns schnell langweilig und wir würden nicht so viel lernen.
Vielleicht ein Beispiel zum Thema „Security through Obscurity“:
Wir hatten einen Kunden, der die Pins von Standard Steckern geändert hat, um zu verhindern, dass Fremde sich über das LMT (Local Maintenance Terminal) mit dem Nodes verbinden können. Und das sollte der Ersatz für echte Security-Maßnahmen sein, auf die dann verzichtet wurde. Wir haben da Social Engineering genutzt, um uns ein passendes Kabel zu besorgen, und das dann nachgebaut.
Sehr oft funktionieren Standardtools mit proprietären Protokollen nicht, da hilft dann Reverse Engineering und eben auch Software-Programmierung.
Ähnliche Fälle hatten wir mit Funkverbindungen. Da sind wir mit SDR (Software Defined Radio) herangegangen und binnen einiger Tage hatten wir das sogenannte proprietäre Protokoll. Ein Kunde hat mal die Funkfrequenz vom WLAN geändert und dachte dann, er sei sicher. Stimmt natürlich nicht.
Kennst Du Security-Vorfälle, bei denen bessere OT-Security tatsächlich Angriffe verhindert hätte? (Gerne mit Beispiel)
Es gibt noch viele Standorte, bei denen Remote Zugriffe nicht richtig kontrolliert wurden. Das gilt noch vermehrt durch den Einsatz von mobilen Geräten wie Handys, Tablets und so. Aber auch “alte” Modems die niemand auf dem Schirm hat – Stichwort “War dialing”.
Bei IIoT-Geräten ist es z.B. manchmal so gewesen, dass eine Verbindung von der OT hin zum neuen Dashboard hergestellt wurde.
Was sind aus Deiner Sicht häufige Fehleinschätzungen oder Falschaussagen, die Dir im Bereich OT-/IoT-Security begegnen?
„Bei uns ist alles sicher, wir haben Firewalls“.
“Wir nutzen nur Netzwerktechnik X, deshalb sind wir sicher“.
Daneben stellen wir oft fest, dass Sicherheitsmaßnahmen falsch umgesetzt oder verstanden wurden. Bei der Segmentierung von Netzwerken ist beispielsweise ein typischer Fehler, dass Prozesse nicht voneinander isoliert sind. Oder dass keine Verschlüsselung aktiviert wurde, insbesondere bei ZigBee, HART-IP oder ähnlichen Funkanwendungen. OT Protokolle können es idR. nicht. IoT-Produktentwickler wollen es nicht, aus Effizienz- oder Kostengründen.
Veraltete Asset-Inventarlisten, Site Assessments und Kommunikationsmatrizen sind gang und gäbe – Wir machen beispielsweise keinen aktiven Penetration Test, solange wir das nicht haben – und die auch erst in Test-Umgebungen.
Was ist aus Deiner Sicht oft die wirkungsvollste technische Sicherheitsmaßnahme bei IoT-Geräten?
Over-the-air-Update-Funktionalität. Denn damit kann ich im Nachhinein auch beim Kunden noch patchen. Und Input immer validieren, um z.B. Injections zu verhindern.
Warum nicht MFA?
MFA ist auch wichtig und sehr wirksam – aber oft falsch implementiert. Da gibt es dann Tokens, die man „brute forcen“ kann.
Was ist eine wichtige Kernbotschaft bei dem Thema?
Unternehmen sollten Security als Träger der Digitalisierung sehen, und nicht als Blocker oder Kostentreiber.
Vielen Dank, Pablo, und weiterhin viel Erfolg!
Übrigens: Der Artikel spiegelt unseren aktuellen Wissensstand wider – aber auch wir lernen jeden Tag dazu. Fehlen aus Ihrer Sicht wesentliche Aspekte, oder haben Sie eine andere Perspektive auf das Thema? Gerne diskutieren wir mit Ihnen und weiteren Experten in Ihrem Hause die gegenwärtigen Entwicklungen vertiefend und freuen uns über Ihr Feedback sowie Anfragen zu einem Austausch.
Und zuletzt noch: Nennungen (oder die fehlende Nennung) von Anbietern stellt keine Empfehlung seitens CyberCompare dar. Empfehlungen sind immer abhängig von der kundenindividuellen Situation.
