Entwicklung zertifizierter Software nach Common Criteria

Erfahrungsbericht „Vom Umbauprozess bis zur Evaluierung“

Die Entwicklung von Softwarekomponenten, die nach Common Criteria (CC) zertifiziert werden sollen, stellt ein Unternehmen vor große Herausforderungen. Mit dem Auftrag zur Entwicklung des Anwendungskonnektors für die Telematikinfrastruktur im Gesundheitswesen mussten wir uns diesen Herausforderungen stellen. [Link zur Referenz „Zertifizierte Entwicklung]

Der Konnektor ist die dezentrale Zugangskomponente zur Telematikinfrastruktur.  Er muss vom Bundesamt für Sicherheit in der Informationstechnik (BSI) nach Common Criteria im Level EAL3+ AVA VAN5 zertifiziert werden. Eine vom BSI anerkannte Prüfstelle nimmt als sachverständige Stelle die Prüfung und Bewertung (Evaluierung) des Konnektors vor. Sie stellt die technische Korrektheit und die inhaltliche Vollständigkeit der Prüfergebnisse sicher und stellt der Zertifizierungsstelle die vollständigen Prüfergebnisse zur Verfügung.

Neben den zu erstellenden Softwarekomponenten ist aber auch der gesamte Software Entwicklungsprozess (Life Cycle Management) Teil dieser Evaluierung. In die Sicherheitsbetrachtung werden die räumlichen und organisatorischen Rahmenbedingungen, die Entwicklungsumgebung und die Prozesse für Softwareverteilung und Maintenance einbezogen. Wichtigstes Ziel ist es, die Integrität des erzeugten Quellcodes sicherzustellen.

Unser Entwicklungsumfeld entsprach zum Zeitpunkt der Auftragserteilung noch nicht diesen hochgesteckten Anforderungen. Die Entwicklung aller Projekte fand in einem Großraumbüro statt. Server und Entwicklungsrechner verfügten über eine Anbindung ans Internet, um die erforderlichen OpenSource Bibliotheken und Updates laden und Recherchen betreiben zu können. Bibliotheken wurden als Binaries geladen und eingebunden. Die Dokumentation erfolgte inline durch JavaDoc-Tags und nach Kundenanforderung.

Zertifizierte Software dagegen muss räumlich und organisatorisch getrennt von anderen Entwicklungen erfolgen. Der Zugang zu Entwicklungsräumen und -systemen muss streng reglementiert und kontrolliert werden. Das Entwicklungsnetzwerk muss von anderen Netzen abgeschottet sein. Für alle in den Sicherheitszielen (Security Target) beschriebenen Sicherheitsanforderungen (Security Functional Requirements – SFR) muss eine detaillierte, stark formalisierte Dokumentation erstellt werden. Alle diese Anforderungen haben wir schrittweise umgesetzt.

Die große Baustelle

Im ersten Schritt wurden die räumlichen Voraussetzungen für eine sichere Software-Entwicklung geschaffen. Ziel war es, ein 2-Schalenmodell (1. Schale Alarmierung, 2. Schale Zugangshemmnis) umzusetzen. Ein Teil des offenen Großraumbüros musste dafür abgetrennt werden. Die neu zu errichtenden Wände und Türen mussten eine Einbruchshemmung nach WK4 aufweisen. Während der Umbauphase wurde hinter einer Staubschutzwand fleißig weitergearbeitet.

Nach und nach nahm der neue Entwicklungsraum Formen an. Was auf den ersten Blick aussieht wie eine einfache Trockenbauwand, besteht in Wirklichkeit aus einbruchshemmenden Spezialplatten mit Stahlbeplankung nach WK4.

Fenster, Wände, Boden, Decke und Türen wurden einbruchshemmend verstärkt und mit Alarmsensoren ausgestattet. Nach 10 Wochen Umbauzeit mit viel Lärm und Staub konnten die Entwickler endlich in „Fort Knox“ einziehen. Zutritt zum Entwicklungsraum haben jetzt nur noch die an der Entwicklung beteiligten Personen nach einer 2-Faktor Authentisierung.