Dipl.-Inform. Carsten Eilers

Mangelhafte (Sicherheits-)Konfigurationsmöglichkeiten kamen zumindest indirekt auch schon bei den vorherigen Einträgen der IoT-Top-10-Liste vor, z.B. bei der Authentifizierung. Da sollte zumindest das Setzen starker Passwörter erzwungen werden, was natürlich voraussetzt, dass die Passwörter überhaupt geändert werden können. Das gleiche gilt für Default-Benutzernamen, auch wenn es dort nicht ganz so kritisch ist wie bei den Passwörtern. Ein Default-Benutzername erleichtert zwar Angriffe auf das zugehörige Passwort, da der Angreifer sich auf das Ermitteln des Passworts konzentrieren kann und nicht vorher noch einen gültigen Benutzernamen herausfinden muss. Aber wenn das Passwort stark genug ist, ist das kein Problem. Wichtiger ist es, dass zwischen Administratoren mit ihren höheren Benutzerrechten und normalen Benutzern mit eingeschränkten Rechten unterschieden wird.

Ein weiterer Punkt ist die Absicherung der Daten während der Übertragung und Speicherung durch Verschlüsselung und Signaturen. Auch hierfür sollte es Konfigurationsmöglichkeiten geben. Sogar dann, wenn z.B. für die Sicherung der Datenübertragung SSL/TLS immer eingeschaltet wäre und sich gar nicht ausschalten ließe wären Möglichkeiten zur Konfiguration der Verschlüsselung nötig. So muss es z.B. möglich sein, unerwünschte Algorithmen und/oder Schlüssellängen auszuschalten.

Außerdem sollte es Möglichkeiten zum sicheren Loggen verschiedener Vorfälle geben. Zumindest alle sicherheitsrelevanten Events sollten sich protokollieren lassen, wie z.B. fehlgeschlagene Login-Versuche, abgewiesene Zugriffe auf Administrations-Funktionen usw.. Zusätzlich sollte es eine Möglichkeit geben, den Benutzer über diese Vorfälle zu informieren, z.B. per E-Mail, Push-Nachrichten etc..

Anforderungen an eine sichere Konfiguration

OWASP listet in der Beschreibung von Punkt 8 explizit die folgenden Punkte auf, auf die geachtet werden muss. Alle setzen natürlich voraus, dass es entsprechende Funktionen auch gibt - es ist ja auch schon vorgekommen, dass eine Administrationsoberfläche Optionen anbietet, die gar keine Funktion haben.

Für die Entwickler der IoT-Geräte bedeutet ist es natürlich relativ einfach, die entsprechenden Funktionen und ihre Konfigurationsmöglichkeiten zu implementieren. Möchte man aber als Außenstehender prüfen, ob eine Konfiguration auch das tut, was sie soll, wird es schwieriger. Um z.B. zu prüfen, ob gespeicherte Daten wirklich wie versprochen mit AES und einem 256 Bit langen Schlüssel gespeichert werden oder ob es nicht vielleicht doch nur eine simple XOR-Verknüpfung der Daten mit dem Schlüssel ist, müsste man entweder den betreffenden Sourcecode, so er denn vorliegt, oder die verschlüsselten Daten eingehend analysieren. Was beides u.U. mit ziemlich viel Aufwand verbunden ist.

Aber kommen wir zu den von OWAPS aufgeführten Punkten, die im Grunde den oben schon genannten Beispielen entsprechen. Es sollte die Möglichkeit geben ...

• ... zwischen normalen Benutzern und Benutzern mit Administrator-Rechten zu unterscheiden,
• ... Daten während der Speicherung und Übertragung zu verschlüsseln,
• ... strenge Passwort-Richtlinien zu erzwingen,
• ... das Protokollieren sicherheitsrelevanter Vorfälle zu aktivieren und
• ... den Benutzer über das Eintreten solcher Vorfälle zu informieren.

Soviel zur "Insufficient Security Configurability". In der nächsten Folge geht es um Punkt 9 der IoT-Top-10: Insecure Software/Firmware, also unsichere Software/Firmware.

Carsten Eilers