OpenSCAP

Direkt zu Beginn eine Warnung. In diesem Tagebucheintrag treten überdurchschnittlich viele Abkürzungen auf. Das hat nichts damit zu tun, dass ich nun auch beim Schreiben von Artikeln möglichst wenig Arbeit investieren möchte. Es liegt daran, dass die IT-Welt nun mal Abkürzungen liebt und dies immer extremer wird, je akademischer und offizieller das Thema wird. Haben Regierungsorganisationen bei der Definition von Standards ihre Finger mit im Spiel, wird es ganz schlimm, aber lesen Sie selbst. Aber denken Sie daran: Ich habe Sie gewarnt.

Wer sich in Deutschland dafür interessiert, wie Computer-Systeme so zu konfigurieren sind, dass sie einem gewissen Sicherheitsstandard entsprechen, wird schnell auf die IT-Grundschutz-Standards des Bundesamts für Sicherheit in der Informationstechnik (BSI) [1] stoßen. Früher gab es sie in einem dicken Schinken, auch als IT-Grundschutzhandbuch bekannt, heute definiert das BSI diverse IT-Grundschutz-Standards und beschreibt sie in den IT-Grundschutz-Katalogen.

Wer sich durch diese Kataloge kämpft, kann schließlich das Zertifikat ISO 27001 beantragen. Diverse Tools helfen dabei, die eigene IT-Landschaft in dieser Hinsicht unter die Lupe zu nehmen und entsprechende Maßnahmen einzuleiten und umzusetzten. Das wohl bekannteste Tool im Open-Source-Bereich ist dabei Verinice [2] von der Sernet GmbH in Göttingen. Verinice ist ein Information Security Management System (ISMS), und es hilft dabei, die einzelnen Bausteine aus den BSI-Grundschutz-Katalogen abzuarbeiten. Da sie weit über die Konfiguration von IT-Systemen hinausgehen, sind eine Vielzahl von einzelnen Anforderungen zu beachten, hier das passende Tool zur Hand zu haben, ist sicher Gold wert.

Auch wenn viele Bausteine des IT-Grundschutz richtig und sinnvoll sind, ist ihre Umsetzung für viele Admins übertrieben, wenn sie gar nicht daran interessiert sind, die entsprechende Zertifizierung für ihre Umgebung zu erlangen. Stattdessen möchte man doch einfach nur sicherstellen, dass die eigenen IT-Systeme auf eine sichere Art und Weise installiert und konfiguriert sind.

In solchen Umgebungen kommen dann die bekannten Security-Guides beziehungsweise Checklisten der NSA [3] oder der Defense Information Systems Agency (DISA) [4] zum Einsatz. Letztere stellt mit den sogenannten Unix Security Technical Implementation Guide (STIG), eine Art De-facto-Standard dar, wenn es um die sichere Konfiguration von Unix- und Linux-Systemen geht. Mithilfe sehr detaillierter Checklisten ist somit jeder Admin in der Lage, seine Systeme auf eine richtige und sichere Konfiguration hin zu überprüfen, angefangen bei der richtigen Partitionierung der Festplatte bis hin zur korrekten Rechtevergabe auf einzelnen Systemdateien.

Die sogenannten System Readiness Review (SRR) Skripte bieten sogar die Möglichkeit, die Checklisten automatisch abarbeiten zu lassen. Auf diese Weise haben sich ganze Legionen von Admins durch die Konfiguration ihrer Systeme gewühlt, immer auf der Suche nach möglichen Fehlkonfigurationen. Der aufmerksame Leser wird sicherlich schon den Haken an der Sache erkannt haben. Der ganze Ansatz skaliert nicht sonderlich gut, da IT-Systeme sich nunmal ständig ändern und sich somit in einem dynamischen Zustand befinden.

Theoretisch

Die Herausgabe neuer Richtlinien und Konfigurationsempfehlungen stellt somit einen gewaltigen Arbeitsaufwand dar. So ist es nicht weiter verwunderlich, das beispielsweise bei der Veröffentlichung von Red Hat Enterprise Linux 6 die aktuell verfügbaren DISA STIGs noch auf RHEL4 basierten. Auch habe ich selbst noch nie die soeben erwähnten SRR Tools im praktischen Einsatz gesehen. Meistens arbeiten Admins die Checklisten manuell ab, was natürlich sehr fehleranfällig ist und ab einer gewissen Größe der Systemlandschaft auch nicht mehr skaliert und nahezu unmöglich wird.

Die DISA hat dieses Problem allerdings auch erkannt und bereits vor gut einem Jahr eine Präsentation zu der Thematik mit dem Titel "STIGs, SCAP, and Data Metrics" veröffentlicht. Dort räumte sie ein, dass sich bei ihrer Prozedur gewisse "Maintenance Challenges" stellen. Anfang 2010 gab die DISA dann eine FAQ heraus, in der deutlich wurde, dass für zukünftige Releases der hauseigenen Richtlinien nur noch auf das Security Content Automation Protocol (SCAP) des National Institute of Standards and Technology (NIST) zurückgegriffen werden soll. SCAP umfasst diverse Standard-Methoden zur Beschreibung von System-Konfigurationen und zum Sicherheitsmanagement. Mit entsprechenden Tools ist es dann möglich, diese XML-basierten Dateien einzulesen und mit der lokalen System-Konfiguration zu vergleichen.

Im Dschungel

SCAP umfasst dabei Standards wie beispielsweise CVE, CCE, CPE, CVSS, OVAL, und XCCDF. Gerade die letzten beiden Standards spielen eine wichtige Rolle. Das Extensible Configuration Checklist Description Format (XCCDF) hilft dabei, Richtlinien zur sicheren Konfiguration von IT-Systemen zu definieren. Um sie zu überprüfen, sind diverse Tests notwendig. Wie sie ablaufen, lässt sich mithilfe der Open Vulnerability and Assessment Language (OVAL) beschreiben.

OVAL-Definitionen lassen sich dabei auch durchaus alleine einsetzen, mithilfe von XCCDF ist es allerdings sehr leicht möglich, gewisse Standards vorzugeben, beispielsweise für eine sinnvolle Konfiguration eines Desktop-Systems oder eines Webservers unter einem Red Hat Enterprise Linux. Red Hat und auch diverse andere Linux- Distributionen stellen seit einiger Zeit ebenfalls ihre Patch-Definitionen in eben diesem OVAL-Format zu Verfügung [5] . Mithilfe entsprechender Scanner lässt sich ein System dann leicht überprüfen, ob auch alle vorhandenen Patches eingespielt wurden. Mit OpenSCAP [6] steht nun ein solcher Scanner als Open-Source-Variante zur Verfügung. OpenSCAP kann problemlos mit den SCAP-Standards umgehen und nette HTML-basierte Reports generieren. Das Tool ist seit Fedora 14 und RHEL6 als RPM-Paket verfügbar und steht standardmäßig in den beiden genannten Distributionen zur Verfügung. Fedora bietet daneben auch ein Paket »openscap-content« . Es enthält neben den OVAL-Definitionen für das System auch ein vorgefertiges Profil mit dem Namen "F14-Default", das auf ein Subset aller zur Verfügung stehenden OVAL-Definitionen zurückgreift, um das System einem Check zu unterziehen. Der entsprechende Aufruf sieht dann wie folgt aus:

oscap xccdf eval --profile "F14-Default"--results fedora.xml --report fedora.html /usr/share/openscap/scap-xccdf.xml

Den so erzeugten HTML-Report kann man sich dann in jedem Webbrowser anschauen. Die hier verwendete XCCDF-Profildatei sollte allerdings nur zu Testzwecken verwendet werden. In der Regel geben die Linux-Distributoren bisher jedoch keine Profil-Dateien heraus und verlassen sich hier auf entsprechende Content-Provider, beispielsweise die DISA oder auch das NIST [9] . Stattdessen gibt es von den Distributoren die gesammelten Sicherheitsmeldungen für die eigenen Software-Pakete im OVAL-Format. Für Red Hat Enterprise Linux stehen diese unter [7] bereit. Mit der »oscap« -Option »--id« besteht auch die Möglichkeit, auf einem System nach einem bestimmten Bugfix zu suchen. So überprüft beispielsweise der folgende Befehl, ob das Advisory "RHSA-2012:0017: libxml2 security update" auf dem System eingespielt wurde:

oscap oval eval --id oval:com.redhat.rhsa:def:20120017 com.redhat.rhsa-all.xml

Natürlich kann der OpenSCAP-Scanner nur dann brauchbar funktionieren, wenn der Content, den er verarbeiten soll, korrekt und aktuell ist. So stellen beispielsweise bisher weder die DISA noch das NIST entsprechende Profile für Red Hat Enterprise Linux 6 zur Verfügung, die letzten Profile basieren alle noch auf RHEL5. Red Hat und andere Distributionen selbst stellen zwar ihre OVAL-Definitionen zur Verfügung, damit alleine erhält man allerdings noch kein System-Profil. Ledigliglich Patch-Zustände lässen sich hiermit nachvollziehen.