Blog Entwicklung zertifizierter Software nach Common Criteria

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.