Sehr geehrtes NetOps-Team: Sicherheitsregel Null gilt auch für Sie

Okay, NetOps. Während Sie mit der Automatisierung beginnen und nach Herzenslust Skripte schreiben, ist es Zeit für eine kleine Erinnerung an die Sicherheit. Ich spreche nicht von Firewalls und WAF oder anderen Sicherheitsdiensten, für deren Bereitstellung und Verwaltung Sie möglicherweise verantwortlich sind. Ich spreche von den Skripten und Codes, die Sie erstellen werden, wenn Sie sich auf die Reise der digitalen Transformation begeben.

Heute möchte ich Sie an die Sicherheitsregel Null erinnern. Zur Auffrischung Ihres Gedächtnisses:

SICHERHEITSREGEL NULL: DU SOLLST BENUTZEREINGABEN NICHT VERTRAUEN. IMMER. 

Ziemlich einfache Regel, oder?

Das sollte so sein, ist es aber nicht. Immer wieder kommt es in der Geschäftswelt zu Verstößen, die auf die Nichteinhaltung der Sicherheitsregel Null zurückzuführen sind. Verstöße gegen diese Regel sind in Beispielcodes, die Entwicklern bei der Recherche und beim Erlernen neuer Sprachen und Frameworks zur Verfügung gestellt werden , weit verbreitet und halten leider auch Einzug in den spannenden neuen Bereich der NetOps.

Darf ich Beweisstück A vorlegen:

Um fair zu sein: Dieses Skript hat zumindest den Anstand, Sie zu warnen, dass die Daten nicht validiert sind. Das ist gut, denn dieses Skript führt anschließend auf Grundlage der Eingabe alle möglichen Fernmanipulationen der Routerkonfigurationen durch.

Was mich daran stört, ist, dass der Code dazu gedacht ist, NetOps die ersten Schritte mit der Skripterstellung zur Automatisierung von Produktionsnetzwerkgeräten zu erklären, und er lediglich auf die Datenvalidierung verweist, ohne hilfreiche Informationen dazu bereitzustellen.

Einige gute Ratschläge zur Validierung von IP-Adressen in Python finden Sie in dieser Stack Overflow-Diskussion .

Aber Lori, das ist Scripting und wir machen CLI-Sachen, und mal ehrlich, wie riskant ist das?

Es ist schwer, schlechte Angewohnheiten abzulegen.

Das Ignorieren der Sicherheitsregel Null bringt zwei Probleme mit sich.

Erstens sind die Tage der CLI gezählt, mein Freund. Die API ist die neue CLI und die meisten Automatisierungsframeworks nutzen RESTful-APIs zur Bereitstellung und Verwaltung von Netzwerkgeräten und -diensten. Das bedeutet App-Stapel und Parser. Damit sind Geräte gemeint, die potenziell anfällig für Angriffe sind, weil ihre Konfiguration über eine API geändert werden kann, die möglicherweise Schwachstellen enthält.

Als Beweis dafür, dass ich nicht übertreibe, biete ich diese Cisco-Warnung hinsichtlich der viel diskutierten Apache Struts-Sicherheitslücke an. Es besteht Konsens darüber, dass die Weitergabe nicht bereinigter Eingaben an das Struts-Framework allerlei schlechte Dinge auslöst.  

Aber nur für den Fall, dass Sie sich angesichts des Ausnutzungspotenzials keine Gedanken über die Durchsetzung der Sicherheitsregel Null machen, möchte ich darauf hinweisen, dass die Reichweite einer unterlassenen Bereinigung der Eingaben weit größer sein kann als die eines einzelnen Geräts. Bedenken Sie, was wir über den Amazon S3-Ausfall Anfang 2017 wissen:  

Um 9:37 Uhr PST führte ein autorisiertes S3-Teammitglied unter Verwendung eines etablierten Playbooks einen Befehl aus, dessen Ziel darin bestand, eine kleine Anzahl von Servern für eines der S3-Subsysteme zu entfernen, das vom S3-Abrechnungsprozess verwendet wird. Leider wurde eine der Eingaben für den Befehl falsch eingegeben und es wurde eine größere Anzahl von Servern entfernt als beabsichtigt.

-- Zusammenfassung der Amazon S3-Dienstunterbrechung in der Region Northern Virginia (US-EAST-1)

Die Zahl, die er in das Skript eingab, war viel größer als beabsichtigt. Aber Skripte, die blind alles akzeptieren, was der Betreiber anbietet (und dabei Sicherheitsregel Null ignorieren), führen zwangsläufig zu solchen Fehlern. Eine einfache – wenn auch zugegebenermaßen lästige – Überprüfung durch das Skript hätte möglicherweise verhindern können, dass das Problem länger als eine Woche lang Gesprächsthema auf Twitter ist.

Im Netzwerk und in der Produktion betrachten wir Sicherheit häufig aus der Perspektive der Autorisierung. Ist Bob befugt, diese Aktion auszuführen? Kann Alice dieses Skript ausführen? Und wir brauchen das, es ist noch immer von entscheidender Bedeutung.

Doch während wir auf unserem Weg der (internen) digitalen Transformation immer schneller vorankommen, mehr Frameworks übernehmen und APIs und Skripte verwenden, um Bereitstellung und Verwaltung weitgehend zu automatisieren, müssen wir die Sicherheit unbedingt auch aus der Entwicklungsperspektive berücksichtigen.

Und die erste dieser Regeln ist Sicherheitsregel Null: DU SOLLST BENUTZEREINGABEN NICHT VERTRAUEN. IMMER. 

Eingabe immer validieren. Dies sorgt nicht nur für zusätzliche Sicherheit, sondern kann auch verhindern, dass eine gute Automatisierung Schaden nimmt.