Die Common Criteria (CC) sind ein international anerkanntes Normenwerk ( ISO 15408), dessen Ziel es ist, die Sicherheit von Computersystemen und Software unparteiisch zu bewerten. Dieses Repository, auch Common Criteria genannt , entstand aus einer Partnerschaft zwischen Kanada, den Vereinigten Staaten und Europa. Dank des angebotenen Frameworks können Benutzer der Informationstechnologie Schutzprofile verwenden, um die erwarteten funktionalen Sicherheitsanforderungen zu spezifizieren, und Bewerter können überprüfen, ob die Produkte dem erforderlichen Sicherheitsniveau entsprechen.
Die Umsetzung der von den Unterzeichnern eines Abkommens über die gegenseitige Anerkennung beschlossenen Gemeinsamen Kriterien erleichtert die Akzeptanz von Sicherheitszertifikaten der Informationstechnologie, die von einem der Unterzeichnerstaaten ausgestellt wurden, erheblich. Das von einer zuständigen Behörde unparteiisch zertifizierte Produkt kann ohne weitere Bewertung verwendet werden.
Trotz vieler Vorteile ist die Anwendung dieser Norm kostspielig, für einen Laien schwer verständlich und oft kompliziert in der Umsetzung. Aus diesem Grund haben sich mehrere Anwendungsmethoden herausgebildet.
1983, dann 1985 veröffentlichten das NIST und die NSA das Orange Book . Der Zweck dieses Dokuments bestand darin, die Fähigkeit eines Systems zur Abwehr von Angriffen zu bewerten.
Gleichzeitig lässt sich Europa von der TCSEC inspirieren , 1991 eigene Bewertungskriterien für die ITSEC zu definieren . Sie werden die Lücken in der Risikoanalyse füllen.
1993 hat Kanada seinen eigenen CTCPEC-Standard definiert.
Das in einem Land erworbene Zertifikat wird nur von den Unterzeichnerstaaten des Abkommens über die gegenseitige Anerkennung anerkannt. In Europa gilt das SOG-IS Abkommen.
Im Jahr 1999 ist die ISO der Ursprung der Common Criteria. Diese Organisation wird die verschiedenen Staaten zusammenbringen, um einen Standard (ISO 15408) zu definieren, der von allen Staaten anerkannt wird, die das CC-MRA-Abkommen im Mai 2000 unterzeichnet haben. Zusätzlich zu den 17 Unterzeichnerstaaten erkennen 9 Nichtunterzeichnerstaaten diese Zertifikate an.
Die Common Criteria (CC) sind ein Leitfaden, der als Referenz für die Entwicklung und Kontrolle von Informationsprodukten und Informationsverarbeitungssystemen dient. Ziel ist der Schutz vor unbefugter Offenlegung, Veränderung, Nutzungsverlust. Die Kategorien dieser drei Fehlertypen werden allgemein als Vertraulichkeit, Integrität und Verfügbarkeit bezeichnet. CCs berücksichtigen die Risiken, die von menschlichen Aktivitäten (böswillig oder nicht) oder nichtmenschlichen Aktivitäten ausgehen.
Kontrollierte Produkte sind diejenigen, die solche Informationen sammeln, transportieren und verarbeiten, nämlich Computernetzwerke , die Betriebssysteme , für verteilte Systeme und Anwendungen. Ein System wird entsprechend dem Verwendungszweck bewertet, für den es bestimmt ist. Es muss zwei Kategorien von Sicherheitsanforderungen erfüllen: Funktions- und Sicherheitsanforderungen.
Die Sicherheitsbedürfnisse der Benutzer sind Anforderungen an die Verfügbarkeit , Vertraulichkeit und Authentizität personenbezogener Daten. Die gemeinsamen Kriterien gelten für drei Benutzerkategorien:
Endverbraucher Endbenutzer können anhand des Bewertungsergebnisses feststellen, ob ein Produkt ihren Anforderungen entspricht. Entwickler Entwickler verwenden CCs, um Sicherheitsanforderungen für ihr Produkt zu identifizieren. Die Gutachter Rezensenten finden die Kriterien, anhand derer beurteilt werden kann, ob ein Produkt sein Bewertungsziel erfüllt. Die Norm beschreibt die zu ergreifenden Maßnahmen, jedoch nicht die zu befolgenden Verfahren.Die gemeinsamen Kriterien sind Gegenstand von drei miteinander verbundenen Dokumenten:
Einführung und allgemeines Modell Dieses Dokument definiert allgemeine Konzepte und stellt ein allgemeines Bewertungsmodell vor. Es bietet auch ein Glossar der verwendeten Begriffe und Schlüsselwörter. Daher werden regelmäßig die folgenden drei Akronyme verwendet: ES TI steht für „Informationstechnologie“. Es ist in der angelsächsischen Literatur auch unter der Abkürzung IT, „ Information Technology “ bekannt. ZEHE TOE ist die Abkürzung für „ Target Of Evaluation “. Der EVG ist das Ziel der Bewertung. Es handelt sich um ein Produkt oder eine evaluierte IT mit der dazugehörigen Dokumentation, die einerseits für den Administrator und andererseits für den Benutzer bestimmt ist. TSF TSF ist die Abkürzung für „ TOE Security Functions “. Es bezeichnet alle Sicherheitsfunktionen des EVG. Funktionale Sicherheitsanforderungen Es ist ein Katalog von funktionalen Sicherheitskomponenten, die in Familien und Klassen eingeteilt sind. Sicherheitsanforderungen Dieses Dokument listet die Anforderungen an den Entwickler und die Aufgaben für den Evaluator auf.Sicherheitsfunktionale Anforderungen beziehen sich nur auf Sicherheitsfunktionsspezifikationen. Sie sind in elf Klassen gruppiert, die jeweils eine Domäne abdecken. Jede Klasse ist in Familien eingeteilt. Jede Familie enthält einen Satz von Komponenten, der eine Sicherheitsanforderung darstellt. Jede Klasse wird durch einen eindeutigen Namen gekennzeichnet, dessen Abkürzung aus drei Fxx-Zeichen besteht: F für funktionale Anforderungsklasse und xx für den Namen der abgedeckten Funktionalität.
FAU-Sicherheitsaudit-Klasse Aufgeteilt in 6 Familien, von denen jede aus 1 bis 4 Sicherheitskomponenten gruppiert:" Sicherheitsaudits umfassen das Erkennen, Aufzeichnen, Speichern und Analysieren von Informationen im Zusammenhang mit sicherheitsbezogenen Aktivitäten . "
Klasse Kommunikation FCO Diese Klasse befasst sich mit der Nichtabstreitbarkeit von Übertragungen und Empfang. Es wird folglich in 2 Familien unterteilt; die erste bezieht sich auf das Senden, die zweite auf den Empfang. Klasse für kryptografische FCS-Unterstützung Sie bezieht sich auf hohe Sicherheit, die die Verwendung kryptographischer Funktionen erfordert . Es besteht auch aus 2 Familien; eine für die Schlüsselverwaltung, die andere für die Generierung dieser Schlüssel. FDP-Benutzerdatenschutzklasse Aufgeteilt in 8 Familien, die in vier Gruppen unterteilt sind, geht es um die Manipulation von Benutzerdaten. FIA-Identifikations- und Authentifizierungsklasse Diese Klasse besteht aus 6 Familien, um den Benutzer zu identifizieren, ihn zu authentifizieren und diese Zugriffsrechte zu verwalten. FMT-Sicherheitsverwaltungsklasse Es ermöglicht unter anderem, Sicherheitsrollen zu definieren. Es ist auch in 6 Familien mit 1 bis 3 Komponenten unterteilt. Datenschutzklasse FPR Die Anforderungen dieser Klasse umfassen den Schutz des Einzelnen vor der Entdeckung oder betrügerischen Verwendung seiner Identität durch andere. TOE FPT-Schutzklasse Sein Zweck besteht darin, den Schutzbedarf der Sicherheitsfunktionen des EVG und nicht mehr des Benutzers zu beschreiben. Die Familien, aus denen es besteht, können als Duplikat der FDP-Klasse erscheinen. FRU-Ressourcennutzungsklasse Drei Familien von Anforderungen an die Verfügbarkeit von Ressourcen bilden diese Klasse: Fehlertoleranz, Ressourcenzuordnung und Priorität von Diensten. Zugangsklasse zum FTA-Bewertungsziel Es legt die funktionalen Anforderungen fest, die zur Steuerung des Aufbaus einer Benutzerverbindung erforderlich sind. Steuern Sie beispielsweise die Anzahl der Sitzungen, ändern Sie die Zugriffsparameter, zeigen Sie einen Verbindungsverlauf an. FTP-Pfadklasse und vertrauenswürdige Kanäle betrifft die Wege, die verwendet werden, um eine sichere Kommunikation zwischen dem Benutzer und der Informationstechnologie, aber auch zwischen TI herzustellen.Der Entwickler wird in der Lage sein, ein Paket von Komponenten aus dieser Liste entsprechend den Funktionalitäten seines Produkts zu definieren. Da diese Liste nicht vollständig ist, kann sie bei Bedarf ergänzt werden. So hat SAFRAN für die Zertifizierung seines biometrischen Gerätes zur Erkennung falscher Finger die SPOD-Familie in die FPT-Klasse aufgenommen. Für die Zertifizierung dieses Produkts hat SAFRAN außerdem Komponenten aus den folgenden Familien ausgewählt:
Die Liste der Versicherungsanforderungen ist die zweite Liste der Common Criteria. Es identifiziert die Punkte, die überprüft werden müssen, damit ein Produkt ein gewisses Vertrauensniveau in Bezug auf die Verwundbarkeit erreicht . Sie deckt die Gültigkeit der Dokumentation und des Produkts bzw. Systems ab. Für den Entwickler ist dies eine Liste von Nachweisen, die er im Rahmen der Bewertung vorlegen muss. Der Assessor kann die durchzuführenden Aufgaben identifizieren, die zu einer Zertifizierung nach den Common Criteria führen.
Diese Liste besteht auch aus Klassen, die ein Thema behandeln. Diese Klassen sind in Familien unterteilt, die Komponenten zusammenfassen. Jede Komponente repräsentiert eine mehr oder weniger fortgeschrittene Bewertungsstufe eines bestimmten Punktes. Sie sind in Versicherungselemente unterteilt. Die Benennung der Klassen erfolgt mit drei Axx-Zeichen: Ein Versicherungskennzeichen gefolgt von zwei Buchstaben zur Kennzeichnung des abgedeckten Gebiets.
Liste der Klassen;
Klasse | Überdachter Bereich |
---|---|
ADV | Entwicklung |
CO | Komposition |
AGD | Dokumentation |
ALC | Lebenszyklus |
AFFE | Bewertung des Schutzprofils |
ASE | Sicherheitszielbewertung |
ASS | Tests |
AVA | Schätzung von Schwachstellen |
Jedes nach der Bewertung nach den gemeinsamen Kriterien ausgestellte Zertifikat garantiert, dass das bewertete Informationssystem einem bestimmten Grad an Sicherheit entspricht. Dies entspricht einer Punktzahl von EAL 1 bis EAL 7 (Evaluation Assurance Level). Diese Stufen sind mit einem Mindestpaket an Sicherheitsanforderungen verbunden. Es gibt sieben hierarchische Ebenen, die den Vertrauensgrad des bewerteten Produkts bestimmen.
Jedes Level enthält die Anforderungen des vorherigen Levels. Sie spiegeln ein Gleichgewicht zwischen dem erreichten Grad an Sicherheit und den Kosten für das Erreichen dieses Grads wider.
Level 1 am günstigsten und erfordert keine Beteiligung des Entwicklers. Es behauptet, dass das Ziel der Evaluierung gemäß den Beschreibungen in der Dokumentation funktioniert. Es werden nur Bedrohungen abgedeckt, die im öffentlichen Bereich identifiziert wurden. Level 2 erfordert die Beteiligung der Entwickler, um Spezifikationsinformationen und durchgeführte Testergebnisse zu kommunizieren. Stufe 3 zeugt von einer Suche nach offensichtlichen Schwachstellen. Level 4 stellt einen guten Kompromiss zwischen Sicherheit und Kosten dar. Es erfordert keine speziellen Kenntnisse oder Fachkenntnisse. Es reagiert auf eine Schwachstelle im Zusammenhang mit Elementarangriffen. Level 5 zeugt von einer Analyse der Sicherheitsfunktionen. Diese Analyse basiert auf den funktionalen Spezifikationen, den vollständigen Spezifikationen der Schnittstellen, den Anleitungen und dem Design des EVG. Stufe 6 für EVG-Entwicklungen in Hochrisikoumgebungen bestimmt. Stufe 7 bisher maximaler Stand. Es erfordert eine formale Darstellung der funktionalen Spezifikationen und ein hohes Anforderungsniveau. SchutzprofileEin Schutzprofil definiert unabhängig von der Implementierung eine Reihe von Sicherheitsanforderungen für eine Produktkategorie. Daher muss ein Client in der Lage sein, ein Schutzprofil zu verwenden, um seine Sicherheitsrichtlinie auszudrücken. Der Vorteil eines solchen Dokuments besteht darin, dass es wiederverwendbar ist. Aus diesem Grund muss es generisch und mit den folgenden Kapiteln strukturiert sein:
Nur Länder, die das Abkommen über die gegenseitige Anerkennung nach den gemeinsamen Kriterien unterzeichnet haben, sind berechtigt, Bescheinigungen auszustellen. Sie sind auch diejenigen, die akzeptieren, dass ihnen ein neues Mitglied beitritt. So wurde Indien die 17 - ten Unterzeichner im Jahr 2013.
Um unparteiisch zu sein, muss die Bewertung eines IT-Produkts von einer unabhängigen Stelle durchgeführt werden. Die für die Bewertungen verantwortlichen Laboratorien sind von den Regierungsstellen der Unterzeichnerstaaten des CCMRA-Abkommens akkreditiert.
In den USA Die NSA leitet das staatliche NIAP-Programm, das für die Sicherheitsbedürfnisse von IT-Kunden und -Designern verantwortlich ist. Es akkreditiert die CCTLs genannten Kompetenzlabore und validiert die Ergebnisse der Bewertung durch Ausstellung oder Nichtausstellung des Abschlusszertifikats. In Frankreich Per Dekret wird die National Information Systems Security Agency (ANSSI) als Zertifizierungsstelle benannt. Diese Agentur hat zwei Rollen:Land | Regierungsorganisation |
---|---|
Australien | Australische Signaldirektion ASD |
Kanada | Canadian Common Criteria Evaluierungs- und Zertifizierungssystem CECS Certification |
Frankreich | Nationale Agentur für die Sicherheit von Informationssystemen ANSSI |
Deutschland | Bundesamt für Sicherheit in der Informationstechnik BSDI |
Indien | Indisches Common Criteria-Zertifizierungssystem IC3S |
Italien | Organismo di Certificazione della Sicurezza Informatica OCSI |
Japan | Japanisches IT-Sicherheitsbewertungs- und Zertifizierungssystem JISEC |
Malaysia | Cybersicherheit Malaysia |
Niederlande | NSCIB betrieben von |
Neuseeland | Direktion für Verteidigungssignale |
Norwegen | SERTIT |
Republik Korea | IT-Sicherheitszertifizierungszentrum (ITSCC) |
Spanien | Organismo de Certificación de la Seguridad de las Tecnologías de la Información |
Schweden | Schwedische Zertifizierungsstelle für IT-Sicherheit FMV / CSEC |
Truthahn | Türkisches Normungsinstitut Common Criteria-Zertifizierungssystem TSE |
England | Britisches IT-Sicherheitsbewertungs- und Zertifizierungssystem |
Vereinigte Staaten | Nationale Informationssicherungspartnerschaft NIAP |
Die Zertifizierung erfolgt in 3 Stufen:
Anfrage zur BewertungDer Sponsor fordert eine Bewertung von seiner für Zertifizierungen zuständigen Regierungsbehörde an. Es liegt in der Verantwortung des Unternehmens:
Der Bewerter kann in die gesamte Produktgestaltung eingreifen. Er muss die Relevanz des Prüfbuches und das Ergebnis dieser vom Sponsor durchgeführten Prüfungen überprüfen. Anschließend erstellt es einen technischen RTE-Bewertungsbericht, der das erreichte Maß an Sicherheit bestätigt.
ZertifizierungDie Zertifizierungsstelle verlässt sich auf den technischen Bewertungsbericht, um das Bewertungszertifikat gemäß den gemeinsamen Kriterien auszustellen oder nicht.
Laut Mellado und Taguchi zahlt sich die Umsetzung der Sicherheitsstrategie in den frühen Phasen des Entwicklungsprozesses aus. Dies schafft ein robusteres System, indem die Sicherheitsschwachstellen verringert werden, die in späteren Entwicklungsstadien gefunden werden können. Laut Lloyd zwingen steigende Kosten und Zeitbeschränkungen viele Unternehmen und die US-Regierung bei der Herstellung und Vermarktung von COTS dazu , Sicherheitsbedenken in ihre Anwendungsentwicklung zu integrieren. Kallberg sagt, dass die gegenseitige Anerkennung des Standards theoretisch Zeit und Geld spart, indem redundante Zusicherungen entfernt werden.
BenutzervertrauenFür Mellado verfügen viele IS-Benutzer nicht über das Wissen und die Ressourcen, um das Sicherheitsniveau der Systeme zu qualifizieren. Die Verwendung von CCs als Grundlage für die Sicherheitsbewertung gibt den Benutzern Vertrauen. Laut Sauveron ermöglicht die Zertifizierung den Kunden, verschiedene Produkte auf dem Markt objektiv zu vergleichen.
Wettbewerbsvorteil der HerstellerSauveron weist darauf hin, dass in bestimmten Märkten (zB Banken) eine Zertifizierung vorgeschrieben ist. Der Hersteller hat somit Zugang zu geschlossenen oder spezialisierten Märkten. Hersteller können die Zertifizierung als Marketingargument nutzen, um ihren Markt zu erweitern.
Kontrolle der Risiken nationaler AngriffeFür Sauveron ermöglicht die Zertifizierung den staatlichen Zertifizierungsstellen, sicherzustellen, dass die in ihren Ländern verwendeten Produkte kontrolliert werden. Und dass daher keine große Gefahr von Angriffen auf ihre Computersysteme besteht.
Laut Mellado und Razzazi wird in den meisten Softwareprojekten die Sicherheit bereits bei der Planung und Inbetriebnahme der Systeme angesprochen. Sehr oft ist die Spezifikation der Sicherheitsanforderungen zu prägnant. Verbraucher sind nicht in der Lage, Anforderungen an die Produktsicherheit klar und eindeutig zu formulieren. Sicherheitsanforderungen werden oft missverstanden. Die Verwaltung von Sicherheitsanforderungen ist für Entwickler ein komplexes Thema. Viele Entwickler neigen dazu, konstruktive Lösungen im Hinblick auf die Schutzmechanismen zu beschreiben, anstatt deklarative Aussagen über das erforderliche Schutzniveau zu machen.
Schwierig und teuerFür Razzazi lassen CCs zu viel Raum für Unklarheiten und es ist oft schwierig, die Bedeutung von Sicherheitsanforderungen genau zu verstehen. Shoichi weist darauf hin, dass die CC-Kriterien sehr abstrakt seien, ein globaler Überblick sei unmöglich. Es ist schwierig, Anforderungen von Grund auf neu zu definieren. Die Erfahrung zeigt, so Keblawi, dass vorgeschriebene Standards unflexibel sind und realitätsnahe Erwägungen ignorieren. Für Taguchi sind die Methoden semantisch sehr komplex und der Lernaufwand daher sehr hoch. Für Preschern bedeutet die Zertifizierung Strenge in den Entwicklungs- und Wartungsprozessen. Heutzutage macht die Zertifizierung einen Großteil der Kosten der Produktentwicklung aus. Hearn weist darauf hin, dass für Systeme, die COTS verwenden, die Systemintegration und die Sicherheitszusammensetzung schwierige Themen sind. Denn sie hängen von den sicherheitstechnischen Prinzipien der eingesetzten COTS und deren Betrieb mit anderen Elementen ab. Diese Arbeit erhöht somit Kosten und Lieferzeiten.
Komplex, für ExpertenLaut Ware sind CCs für Nicht-Sicherheitsleute schwer zu verstehen. Keblawi behauptet, dass es im Sicherheitsbereich zwar analytische Methoden wie Sicherheitsplanung und Risikoanalysen gibt, diese aber nie in einem Entwicklungsprozess konzeptioniert wurden. Ein weiterer entscheidender Punkt, der in bestehenden Methoden fehlt, ist für Taguchi, dass es keinen Standard gibt, wie die Sicherheitseigenschaften von Informationssystemen im Prozess der Systementwicklung prägnant und systematisch dokumentiert werden können. Ohne einen Bewertungsmechanismus ist der Prozess laut Shoichi langwierig und teuer, weil er für Verifizierer, die keine Mathematiker sind oder mit formalen Methoden vertraut sind, nicht leicht zugänglich ist. Laut Lloyd ist es schwierig, Sicherheitsanforderungen zu spezifizieren, da die Anforderungen sowohl funktionale als auch nicht-funktionale Aspekte umfassen und viele Entwickler möglicherweise nicht mit allen Sicherheitsproblemen vertraut sind, die angegangen werden müssen.
Gilt nicht immer nurDen aktuellen Systemen fehlt laut Razzazi die technologische Basis, um neue Anforderungen an die IT-Sicherheit zu erfüllen. Keblawi weist darauf hin, dass einige Systeme nicht ohne weiteres den Common Criteria-Sicherheitskonzepten entsprechen. Für Lloyd sind aufgrund des geringeren Funktionsumfangs im Vergleich zu IT-Systemen nicht alle CC-Anforderungen direkt auf einzelne COTS-Komponenten übertragbar.
Branchen- und VerbrauchervisionCC-Schutzstufen werden laut Ware in der Praxis selten verwendet. Für Taguchi sind CCs in der Industrie aufgrund der Diskrepanz zwischen einem bestehenden Softwareentwicklungsprozess und CC-Methoden nicht einfach anwendbar. Laut Hearn sehen Verkäufer CCs nicht als Produktverbesserungsprozess. Das Kosten-Nutzen-Verhältnis, das ein Einsatz von CC auf einem Computersystem haben kann, ist nicht abschätzbar. Für Isa weisen viele Forscher und Industrievertreter darauf hin, dass die Praxis von CC in einer sich schnell verändernden Welt nur im „utopischen“ Kontext von CC existieren kann. Laut Kallberg werden CCs mit der Zunahme der industriellen Kriegsführung wahrscheinlich keine kritische Masse als globale Zertifizierungsplattform erreichen. Einkäufer sehen Zertifizierungen laut Hearn als untergeordnetes Kriterium bei der Beschaffung. Sie lesen selten das Sicherheits- oder Zertifizierungsziel und was bewertet wurde. Der Verbraucher beschäftigt sich nicht mit CC-Prozessen, bei denen der Sicherheitsbegriff und das Bedrohungsmodell zu vage sind, um nützlich zu sein.
Vertrauen der RegierungEinige Hindernisse, sagte Hearn, beziehen sich auf Bedenken hinsichtlich der Harmonisierung der Bewertungen zwischen den Ländern. Konflikte zwischen internationaler Harmonisierung und inländischen Investitionen könnten besonders wichtig werden, wenn die großen europäischen Länder und die Vereinigten Staaten bei der Verfolgung nationaler Interessen weiterhin immer divergierende Wege gehen. Auch wenn die Gründungsmitgliedstaaten auf eine Harmonisierung hinarbeiten konnten, zeigt die Erfahrung, dass die Umsetzung der Details divergiert. Für Isa fehlt das Interesse von Käufern und Verkäufern, da CCs von Regierungen kommen und die Implementierungspreise erhöhen. Hearn sagt, dass das Geschäftsinteresse gering ist, da Zertifizierungen das Ergebnis staatlicher Regulierung oder staatlicher Beschaffung sind.
Die von Taguchi vorgeschlagene Methode basiert auf einem Use-Case-Diagramm nach mehreren Prinzipien. Das erste dieser Prinzipien ist die Verwendung eines Diagramms, das die Sicherheitskonzepte detailliert beschreibt, um die Sicherheitsanforderungen aufzuzeigen. Alle Konzepte im Diagramm sind dann Elemente eines CC-Metamodells. Schließlich werden die Sicherheitsmodelle gemäß den Sicherheitsbeschränkungen jeder Phase der Konstruktion des Produkts hinzugefügt.
Diese Methode verwendet ein vom CC abgeleitetes Metamodell, das Teil der Sicherheitsfunktionalität des EVG ist. Die folgenden CC-Konzepte werden beibehalten:
Der Autor beschließt, die folgenden CC-Konzepte aus seinem Metamodell zu entfernen:
Ein Prototypdiagramm wird in 3 Phasen vorgeschlagen. In der ersten Phase ( Grundlegende Sicherheitsanforderungen ) werden Sicherheitsfunktionen und Sicherheitsbedrohungen abstrakt analysiert. Die zweite ( Sicherheitsanforderungen und Zielsetzung ) analysiert die Sicherheitsanforderungen im Detail, um Sicherheitsziele zu definieren. Diese Arbeiten werden ausgehend von den Ergebnissen der Phase 1 durchgeführt. Und schließlich dient Phase 3 ( Auswahl der funktionalen Sicherheitsanforderungen ) der Auswahl der funktionalen Sicherheitsanforderungen, die die in der vorherigen Phase identifizierten Sicherheitsziele erfüllen. Diese Aufgabe wird mit dem CC Teil 2 Standard und Schutzprofilen durchgeführt. Anschließend werden die Sicherheitsanforderungen mit den Versicherungsanforderungen nach der CC-Methodik abgeglichen.
Die von Ware vorgeschlagene Methode besteht darin, die Profile der Akteure zu verwenden, um die Sicherheitsbedrohungen zu erkennen. Führen Sie dann die Kartierung von Bedrohungen und Sicherheitszielen durch. Führen Sie schließlich die Abbildung von Sicherheitszielen und Sicherheitsanforderungen durch. Das Mapping erfolgt über eine Toolbox, die eine Liste von Bedrohungen, Zielen und funktionalen Anforderungen der CCs enthält. Um diesen Ansatz zu implementieren, wird ein grafisches Open-Source-UML-Modellierungswerkzeug vorgeschlagen.
Das Tool zeigt in seiner „Bedrohungstabelle“ anschaulich die zur Abwehr einer bestimmten Bedrohung erforderlichen Ziele und die zur Erreichung eines bestimmten Ziels erforderlichen Anforderungen.
Anschließend bietet das Tool dem Benutzer an, eine Ausgabedatei im HTML-Format zu generieren. Das Tool bietet zwei mögliche Berichtsstile:
Der Bericht „CC-Prinzip“ zielt darauf ab, den Teil der Begründung für ein EVG-Sicherheitsziel zu erbringen. Darüber hinaus zeigen die Spiele deutlich, welche Ziele erforderlich sind, um einer bestimmten Bedrohung zu begegnen, und welche Anforderungen erforderlich sind, um ein bestimmtes Ziel zu erreichen.
Die von Vetterling vorgeschlagene Methode ist ein Prozess, der die „phasenorientierte“ Softwareentwicklung mit den von CCs geforderten Aktivitäten kombiniert. Das Prinzip besteht darin, die Aktivitäten der CCs in die Entwicklungsphasen des Projekts zu integrieren. Diese Methode basiert auf einem iterativen Prozess in jeder Phase des Projekts. Am Ende jeder Iteration kann das Ergebnis ausgewertet werden. Die nächste Iteration beginnt mit dem Ergebnis der vorherigen Phase, wobei neue Anforderungen hinzugefügt werden.
In der Planungsphase wird der Configuration Management Plan (Klasse ACM) geschrieben. Das Lebenszyklushandbuch (Klasse ALC) wird ebenfalls entsprechend der gewählten EAL-Stufe erstellt. In dieser Phase sollte entschieden werden, wie hoch die EAL ist und welcher Teil des Systems oder Produkts in Übereinstimmung mit den CCs entwickelt werden soll.
In der Analysephase wird das Sicherheitsziel (Klasse ASE) entworfen. In dieser Phase beginnen wir auch mit dem Schreiben der ersten Versionen des Testdokuments (Klasse ATE) und der Benutzerhandbücher (Klasse AGD).
In der Entwurfsphase beginnt die Ausarbeitung des Entwurfs und der Darstellung (Klasse ADV). Der Detaillierungsgrad hängt von der ausgewählten EAL-Stufe ab. In dieser Phase wird auch das Vulnerability Assessment (AVA-Klasse) initiiert. Diese Phase liefert Informationen zu Benutzerhandbüchern (AGD-Klasse).
In der Entwicklungsphase gibt es Elemente der Testergebnisanalyse, die für die Testdokumentation wichtig sein werden (Klasse ATE). Für die höchsten EAL-Stufen muss das Entwurfs- und Darstellungsdokument (ADV-Klasse) mit einer Darstellung der Implementierung ergänzt werden. In dieser Entwicklungsphase werden die Schwachstellenbewertung (AVA-Klasse) und die Benutzerhandbücher fertiggestellt. In der Entwicklungsphase werden auch die Dokumentationen für Lieferungen und Betrieb (ADO-Klasse) erstellt.
In der Bereitstellungs- und Inbetriebnahmephase werden die Unterlagen für die Lieferungen (ADO-Klasse) fertiggestellt.
Es wurde eine Fallstudie zur Entwicklung einer Anwendung für elektronische Geldbörsen durchgeführt. Das Projekt dauerte 3 Monate mit einem Team von 18 Personen mit einer Arbeitsbelastung von 630 Manntagen.
Das erste Feedback ist, dass die CCs zu viel Raum für Unklarheiten lassen, es ist oft schwierig, die richtige Bedeutung der Sicherheitsanforderungen zu finden. Unterschiedliche Interpretationen von CC-Anforderungen sind oft möglich und verschwenden wertvolle Zeit während des Projekts.
CCs machen Dokumente voneinander abhängig, was den Dokumentenaufwand erhöht. Dieser Dokumentationsaufwand wird auch dadurch erhöht, dass die CC-Anforderung Spezifikationen auf unterschiedlichen Abstraktionsebenen positioniert. Der Umfang der funktionalen Anforderungen von CC liegt hauptsächlich im Bereich der Kommunikationsnetze und des elektronischen Geschäftsverkehrs. Sie deckt die Anforderungen an die Sicherheit der Privatsphäre der Benutzer oder die Anforderungen des fairen Handels nicht angemessen ab.
José Romero-Mariona, schlägt einen Ansatz vor, der die Sicherheitsanforderungen der CCs an die Architekturelemente und deren Verbindungen anpasst. Die Methode bietet einen Leitfaden, der in erster Linie auf Beobachtungen aus dem CC-Prozess basiert: Sicherheitsanforderungen entwickeln. Mit Hilfe dieses Leitfadens sollen Benutzer in der Lage sein, diese Anforderungen an die Architekturelemente und deren Verbindungen abzubilden.
Aus diesem Mapping automatisiert dann ein Tool die Erstellung einer XML- Datei, nachdem es eine Überprüfung des Mappings durchgeführt hat. Die Hauptmodule des Tools sind:
Die Komponenten der CCs und deren Verbindungen werden in XML durch 4 Parameter definiert:
Das zweite Modul führt eine benutzerdefinierte Definitionsprüfung durch und erzeugt einen Digraph in einem nicht standardmäßigen XDR-Format. Wenn ein Fehler auftritt, zeigt das Tool diesen an und informiert den Benutzer darüber, was zur Behebung des Problems zu tun ist. Das dritte Modul generiert automatisch eine Ausgabedatei im XML-Format. Der Benutzer kann dann neue Komponenten hinzufügen. Das Tool erstellt eine neue XML-Datei, die als Eingabe an das zweite Modul zur Überprüfung zurückgegeben werden kann.
Shanai Ardi schlägt eine Methode vor, die darin besteht, das Sicherheitsziel durch das Hinzufügen von Software-Schwachstellen zu ergänzen. Das Sicherheitsziel adressiert Folgendes: