Klaus Haller, 3.5.2020

Im April 2020 habe ich die Spezialisierung «Computer Security and System Management» bei Coursera abschliessen können, gehalten von Greg Williams von der University of Colorado in Colorado Springs. Sie umfasst vier Kurse:

• Enterprise System Management and Security
• Windows Server Management and Security
• Linux Server Management and Security
• Planning, Auditing, and Maintaining Enterprise Systems

Wer mich besser kennt, wundert sich, warum ich mich für solche grundlegenden Kurse interessiere. Ich habe ja Zertifikate für CISSP, ISO 27001 Lead Implementor Zertifikate, und auch noch den AWS Solutions Architect Associate. Dazu kommen einige Jahre Leitungserfahrung in Projekten mit IAM-Bezug, AI4Ops, Data Loss Prevention und Compliance. Doch der Grund ist einfach: Ich habe nie als Administrator gearbeitet und möchte gerade bei diesen Themen für Unterhaltungen mehr Hintergrundwissen haben. Doch nun zu dem, was ich gelernt habe. Wir beginnen mit dem ersten Kurs, Enterprise System Management und Security.

Enterprise System Management and Security

Home-/Consumer-Computing und Enterprise-Computing haben andere Charakteristiken, die sich auf den Umgang mit IT-Sicherheit auswirken. Beim Home-Computing geht es um Bequemlichkeit. Ich kaufe etwas, damit das Leben einfacher und angenehmer wird. Der initiale Einkaufpreis ist wichtig, der Service anschliessend weniger. Die Geräte werden gekauft, installiert und laufen dann für Jahre. Sie werden nicht mehr angefasst oder gewartet. Von daher ist es verständlich, warum Microsoft oder Apple auf Laptops quasi automatisch Betriebssystemupgrades einspielen – und dass so viele Menschen alte Android-Versionen auf ihrem Handy haben.

Im Business-Umfeld und beim Enterprise-Computing geht es nicht um Bequemlichkeit, sondern um Notwendigkeit. Ohne Informatik funktionieren Firmen nicht. Sicherheit, Kosten (nicht nur der initiale Kaufpreis), Zuverlässigkeit, Skalierbarkeit etc. spielen eine grosse Rolle. Dies hat Auswirkungen auf die Beschaffung von IT-Geräten. Auf einmal ist zum Beispiel der «Mean time to failure» zentral für Kaufentscheidungen. Diese Denkweise erklärt auch, warum Wifi im Enterprise-Bereich nicht immer so weit verbreitet ist wie im Home-Computing – denn ein unterbrechungsfreier 7/24-Betrieb mit hohen Bandbreiten und vielen Benutzern kann eine Herausforderung zu sein, so der Dozent.

Besonders spannend fand ich das Thema Server-Virtualisierung. Oft werden die Kostenvorteile bentont und dass so Server viel schneller bereitgestellt werden. Doch Server-Virtualisierung bietet auch ein Plus an Sicherheit. Applikationen, die auf einer Virtual Machine laufen, sind viel besser isoliert, als wenn zwei Applikationen auf dem gleichen Server laufen.

Damit war der Schwenk zum Thema Security gemacht. Natürlich wurde die CIA-Triade behandelt. Was mir noch stärker in Erinnerung blieb, waren zwei Prinzipien für IT-Sicherheit:

1. Es gibt keine (dauerhaft) sichere Systeme, sondern nur gegen bestimmte Risiken zu einem bestimmten Zeitpunkt geschützte.
2. Defense in Depth ist zentral, also die Kombination verschiedener IT-Security-Prinzipien, so dass nicht alles zusammenbricht, wenn eine Komponente nicht wie gewünscht funktioniert.

Hinsichtlich des Designs von Netzwerken gibt es drei Ziele. Liest man sie, so wirken sie vielleicht trivial. Doch ausformuliert verdeutlichen sie wichtige Konzepte:

1. Keep Outsiders Out: externe Personen oder Angreifer bekommen keinen Zugang zum Netzwerk
2. Keep Insiders In: Mitarbeiter, die im Netzwerk arbeiten, muss man vor sich selbst schützen. Dabei kann es um technische Ziele gehen, wie zum Beispiel Virenschutz oder auch um Compliance-Vorschriften, wie zum Beispiel HIPPA.
3. Keep Insiders Out: Mitarbeitende, die legitim im Netzwerk sind und dort arbeiten, bekommen trotzdem nicht Zugriff auf alle (!) Daten beziehungsweise nur auf Daten, die sie benötigen («need to know»).

Windows Server Management and Security

Einstiegsfrage war, wie einige Microsoft-Produkte einzuordnen sind. Dabei ist die Aussage, dass Windows ein vollwertiges Serverbetriebssystem ist und die Microsoftprodukte für das User Management (Active Directory) und für Authentisierung (ADFS, Kerberos) einen Mehrwert gegenüber anderen Produkten bieten.

Nach Meinung des Dozenten zeichnet sich Windows als Betriebssystem aus Security-Sicht dadurch aus, dass es:

• leicht zu managen ist
• eine Antivirus-Lösung integriert hat
• diverse (weitere) Security-Features und Verschlüsselung beinhaltet.

Beispiele dafür sind Windows Defender, Anti-Malware-Lösung, um Files und Prozesse zu scannen, sowohl für den User als auch für den Administrator. Weitere Beispiele sind eine Firewall oder Secure Boot. Diese Sicherheitsmechanismen sind für User (nahezu) transparent und könnenleicht eingerichtet werden.

Daneben gibt es zweite Gruppe von Lösungen und Features, gerade im Zusammenhang mit Virtualisierung wie zum Beispiel Virtual Based Security, Device Guard, Credential Guard, Data Execution Prevention. Sie bieten weitergehenden Schutz, sind aber komplexer zu konfigurieren und nicht immer nahezu transparent für die Anwender. Gerade das Wissen von diesen zwei verschiedenen Arten von Security-Lösungen bei Microsoft Windows fand ich sehr interessant.

Drei weitere Punkte sind mir weiterhin in Erinnerung geblieben:

• Das Kerberos-Protokoll, mit dem ich in einem Projekt bereits zu tun hatte (als Projektleiter, weniger aus technischer Sicht) als eine Lösung, die eine Authentisierung stark dezentralisiert, um ein Bottleneck zu vermeiden.
• Die Möglichkeit, die Applikationen o.ä. auf einem Windows-Server zu reduzieren und damit das Exposure gegenüber Angriffen. Das hatte ich vorher vor allem mit Linux in Verbindung gebracht.
• Die zwei Möglichkeiten zur Datensicherung «auf Platte». Da ist zunächst die Windows-integrierte Lösung Filebased Encryption EFS (mit der Möglichkeit auf Filezugriff durch verschiedene Mitarbeiter) und, als Alternative, Bitlocker zum Verschlüsseln des ganzen Laufwerks, welches aber ein Trusted Platform Module benötigt: Mehr Aufwand und mehr Kosten – dafür ist die Sicherheit höher.

Linux Server Management and Security

Greg Wiliams sieht als typische Einsatzgebiete von Linux Industrial Control Systems, Web und File Server, Domain Name Server (DNS) und Big Data-Lösungen.

Die Charakteristiken von Linux lassen sich am leichtesten im Vergleich zu Windows darstellen. Dabei gefällt mir die Formulierung des Dozenten «Linux vergibt nicht.» wirklich gut. Sie veranschaulicht, dass man ein Linux-System mit wenigen oder gar nur einem Befehl – zum Beispiel File Deletes oder Packageupgrades – komplett ruinieren kann, ohne Chance, dies mit begrenztem Aufwand wieder zurückzunehmen. Da wundert es nicht, dass der Dozent auch darauf hinweist, dass man bei Linux technisch viel stärker am Ball bleiben muss als bei anderer Software.

Generell ist der Markt bei Linux mit vermutlich über 1000 Distributionen natürlich viel uneinheitlicher als man das von Windows her kennt. So wundert es nicht, dass beispielsweise Ubuntu und Red Hat verschiedene Packagemanager einsetzen (APT bei Ubuntu, YUM bei Red Hat). Gemeinsam ist per Definition zwischen verschiedenen Distributionen nur der eigentliche Linux-Kernel.

Linux ist ein sicheres Betriebssystem (man denke nur an die vielen Sudo-Befehle, die ein Administrator absetzen wird pro Tag – ohne sich jemals als Root einloggen zu müssen). Gleichzeitig ist das Konzept «User-Gruppe-Welt» in der heutigen Welt natürlich nichts mehr ausreichend. Das erklärt einerseits den Erfolg von Microsofts Active Directory. Aber auch innerhalb der Linux-Community gibt es Lösungen, darunter SELinux – Security Enhanced Linux, was sich beispielsweise in Android ab Version 4.3 oder in Red Hat Enterprise Linux findet und viel feingranulare Lösungen beispielsweise für Zugriffsrechte enthält.

Planning, Auditing, and Maintaining Enterprise Systems

Im vierten und letzten Kurs meiner Spezialisierung «Computer Security and System Management» ging es um übergreifende Security-Fragen und organisatorische Themen. Einige Themen kannte ich aus den ITIL/CISSP/ ISO27001-Umfeldern besser. Was ich spannend fand, das war die Präzisierung intuitiv verständlicher Begriffe wie «Attack Surface», die so operationalisierbar werden.

Eine Attack Surface besteht aus vier Komponenten:

• Alle Pfade für Daten und Befehle, um in die Applikation zu kommen, egal ob es um http-Header geht oder Cookies, um UIs oder um Files und Datenbanken. Oft geht die Zahl in de Tausende, so dass eine Gruppierung in Login, Business Workflows, APIs etc.) hilft.
• Dem Code, der im Zusammenhang mit dem Schutz solcher Pfade steht, also mit der Autorisierungsfunktionalität, Verbindungen, Logging etc.
• Alle sensiblen Daten. Das können Daten mit Bezug zu der Geschäftstätigkeit sein wie Business Data oder Intellectual Property oder technische Daten wie Schlüssel und Geheimnisse/Passwörter.)
• Code, der im Zusammenhang mit dem Schutz sensibler Daten hilft.

Die Attack Surface ist bei den meisten Applikationen zu gross, um vollständig analysiert zu werden. Daher ist das Ziel einer entsprechenden Analyse, eine Übersicht über das System zu bekommen und High-Risk-Bereiche im Code zu identifizieren. Diese werden dann besonders geschützt (Defense in Depth). Generell können Tools wie OWAS ZAP für den Scan von Applikationen den Analyseaufwand stark reduzieren.

Denkt man nun über den Lebenszyklus einer Applikation mit vielen Releases, bringen Metriken wie der Relative Attack Surface Quotient einen Mehrwert. Ein Entwickler, Architekt oder IT Risk Manager kann eine neue Version einer Applikation hinsichtlich Sicherheit mit der vorherigen vergleichen. Jeder sieht sofort, ob man sich verbessert oder verschlechtert.

Zwei weitere Themen, die mir noch besonders gefallen haben, waren das Verhältnis von IT Security und Anwendern und Policies. Bei Policies unterscheidet der Dozent zwei Arten:

• Organisatorische Policies definieren, warum wir etwas machen und sind die Grundlage für detaillierte technische Policies. Beispiele für organisatorische Policies sind eine Acceptable Use Policy oder eine E-Mail Policy. Sie legen beispielsweise fest, zu welchen Zwecken gewisse IT-Services eines Unternehmens genützt werden dürfen.
• Technische Policies sind üblicherweise deutlich ausführlicher und länger. Sie definiert Zuständigkeiten und Verantwortlichkeiten von Mitarbeitern, Usern oder Lieferanten. Beispiele sind Anti-Malware-Policies oder Password-Policies. Auch wenn sie technische Policies heissen, sollte man auf das Benennen konkreter Technologien verzichten, da sich diese zu schnell ändern können. Das ist eher etwas für Standardprozeduren oder Best Practices.

Zum Verhältnis von IT Security und Anwendern war ein Satz des Dozenten zentral für mich: IT Security darf nicht zu einer Last für den Anwender werden. Wenn man zu viel verbietet, suchen Anwender eine Umgehungslösung und man hat nichts gewonnen. IT-Sicherheit erreicht man nur durch partnerschaftliches Verhalten zwischen Anwendern und IT-Abteilung.

Mein Fazit

Hat sich also die Spezialisierung für mich gelohnt? Das kann ich klar bejahen. Ich habe mit der Sicherheit einzelner Server und Computer noch nicht in der Tiefe zu tun gehabt – dieses Wissen konnte ich jetzt aufbauen. Gleichzeitig habe ich bei den rund acht Tagen Online-Learning in die Gedankenwelten und Prinzipien des Dozenten stärker eintauchen können, als das Kurzvorträge ermöglichen – und gerade die Begriffsklärung von scheinbar selbstverständlichen Begriffen tragen oft zu einem vertieften Verständnis der Materie bei.

Die spannendste Frage ist aber noch offen: Wie, wann und wo werde ich dieses Wissen in praktischen IT-Security-Projekten in naher Zukunft einsetzen? ?