───────
la metodologie
──────────────
CERINŢE
de evaluare şi certificare a sistemelor criptografice destinate protecţiei
informaţiilor naţionale clasificate, altele decât cele din categoria
cifrului de stat
Pentru protecţia informaţiilor naţionale clasificate sunt utilizate sisteme criptografice evaluate şi certificate, dupã cum urmeazã:
A. Sisteme criptografice dezvoltate pe plan naţional
a) Pentru protecţia informaţiilor clasificate SECRET DE SERVICIU, sistemele criptografice trebuie sã fie:
(i) evaluate de o entitate evaluatoare acreditatã de Oficiul Registrului Naţional al Informaţiilor Secrete de Stat, denumit în continuare ORNISS; şi
(ii) certificate de o comisie coordonatã de ORNISS.
b) Pentru protecţia informaţiilor clasificate SECRET, sistemele criptografice trebuie sã fie:
(i) evaluate de o entitate evaluatoare acreditatã de ORNISS; şi
(ii) certificate de ORNISS.
c) Pentru protecţia informaţiilor clasificate STRICT SECRET, sistemele criptografice trebuie sã fie:
(i) evaluate de douã entitãţi evaluatoare acreditate de ORNISS; şi
(ii) certificate de ORNISS;
(iii) în cazul în care nu existã douã entitãţi evaluatoare acreditate care sã aibã capacitatea de a realiza evaluarea, sistemele trebuie sã fie:
1. evaluate de o entitate evaluatoare acreditatã de ORNISS; şi
2. certificate de o comisie coordonatã de ORNISS şi formatã din reprezentanţi ai tuturor entitãţilor evaluatoare acreditate de ORNISS pentru a desfãşura activitãţi de evaluare criptograficã.
d) Pentru protecţia informaţiilor clasificate STRICT SECRET DE IMPORTANŢÃ DEOSEBITÃ, sistemele criptografice trebuie sã fie:
(i) evaluate de douã entitãţi evaluatoare acreditate de ORNISS; şi
(ii) certificate de o comisie coordonatã de ORNISS şi formatã din reprezentanţi ai entitãţilor evaluatoare implicate.
B. Sisteme criptografice realizate de producãtori externi
a) Pentru protecţia informaţiilor clasificate SECRET DE SERVICIU pot fi utilizate sistemele aflate în una dintre urmãtoarele situaţii:
(i) certificate pentru cel puţin nivelul echivalent de clasificare de cãtre una dintre urmãtoarele:
1. structuri specializate ale NATO;
2. structuri specializate ale UE;
3. un stat membru NATO sau UE;
4. state cu care România a încheiat înţelegeri, acorduri, aranjamente bilaterale, la nivel guvernamental sau departamental;
(ii) evaluate de o entitate evaluatoare acreditatã de ORNISS şi certificate de o comisie coordonatã de ORNISS.
b) Pentru protecţia informaţiilor clasificate SECRET pot fi utilizate sistemele aflate în una dintre urmãtoarele situaţii:
(i) certificate pentru un nivel superior de clasificare de cãtre una dintre urmãtoarele:
1. structuri specializate ale NATO;
2. structuri specializate ale UE;
(ii) certificate pentru un nivel superior de clasificare de cãtre structuri specializate din state membre NATO sau UE, evaluate de douã entitãţi evaluatoare acreditate de ORNISS şi certificate de ORNISS;
(iii) certificate pentru un nivel superior de clasificare de cãtre autoritãţi competente din state cu care România a încheiat aranjamente de securitate privind recunoaşterea reciprocã a certificatelor de conformitate pentru produse de securitate IT, evaluate de douã entitãţi evaluatoare acreditate de ORNISS şi certificate de ORNISS.
c) Pentru protecţia informaţiilor clasificate STRICT SECRET pot fi utilizate sisteme care îndeplinesc cumulativ urmãtoarele cerinţe:
(i) sunt modele certificate pentru un nivel echivalent de clasificare de cãtre structuri ale NATO, UE, autoritãţi competente din state membre NATO sau UE, state cu care România a încheiat aranjamente de securitate privind recunoaşterea reciprocã a certificatelor de conformitate pentru produse de securitate IT;
(ii) particularizate prin implementarea de algoritmi criptografici naţionali certificaţi;
(iii) evaluate de douã entitãţi evaluatoare acreditate de ORNISS;
(iv) certificate de ORNISS.
d) Pentru protecţia informaţiilor clasificate STRICT SECRET DE IMPORTANŢÃ DEOSEBITÃ nu este permisã utilizarea de sisteme criptografice realizate de producãtori externi.
Prin excepţie de la prevederile lit. A şi B, sistemele criptografice utilizate de autoritãţile desemnate de securitate (ADS) pentru destinaţii specifice se evalueazã de cãtre o entitate evaluatoare acreditatã de ORNISS şi sunt certificate de cãtre structura INFOSEC acreditatã de ORNISS în cadrul ADS. În cazul în care nu existã o structurã INFOSEC acreditatã, certificarea produselor se realizeazã de cãtre ORNISS.
ANEXA 2
───────
la metodologie
──────────────
LISTA DEMONSTRATIVÃ
cu activitãţi aferente procesului de evaluare
1. Prezentãm în continuare o listã exemplificativã cu activitãţi aferente procesului de evaluare:
a) verificarea analizei de conformitate;
b) verificarea analizei caracterului unitar;
c) examinarea eficienţei mecanismelor de asigurare a securitãţii;
d) examinarea vulnerabilitãţilor constructive;
e) examinarea uşurinţei de utilizare;
f) examinarea vulnerabilitãţilor operaţionale;
g) verificarea cerinţelor;
h) verificarea proiectului de arhitecturã a produsului;
i) verificarea proiectului detaliat;
j) verificarea implementãrii mecanismelor de asigurare a securitãţii;
k) verificarea mediului de dezvoltare;
l) verificarea documentaţiei de operare;
m) verificarea mediului operaţional;
n) realizarea de teste de penetrare;
o) întocmirea raportului de evaluare.
2. Pentru claritate, precizãm cã termenul "verificare" implicã analiza elementelor de evaluare, în timp ce termenul "examinarea" furnizeazã date de intrare pentru realizarea testelor de penetrare. Deşi testele de penetrare sunt în mod explicit corelate cu activitãţile anterioare, acestea au fost specificate ca activitate distinctã din douã motive:
a) pentru a sublinia faptul cã analizele anterioare trebuie consolidate şi apoi trebuie concepute testele, pe baza acestor analize;
b) pentru a indica faptul cã, în general, diferitele teste de penetrare sunt realizate împreunã.
3. Prin activitatea de verificare a analizei de conformitate evaluatorul verificã analiza efectuatã de dezvoltatorul produsului. Verificarea poate pune în evidenţã unele vulnerabilitãţi rezultate, din cauza faptului cã anumite funcţii de securitate nu asigurã atingerea unuia dintre obiectivele securitãţii, în condiţiile unei ameninţãri identificate în ţinta de securitate.
4. Activitatea de verificare a analizei caracterului unitar constã în examinarea analizei efectuate de dezvoltatorul produsului şi stabileşte dacã setul de funcţii de securitate implementate, luate ca ansamblu, asigurã în mod adecvat îndeplinirea obiectivelor securitãţii.
5. Prin examinarea eficienţei mecanismelor de asigurare a securitãţii evaluatorul identificã eventualele mecanisme care nu ating eficienţa minimã cerutã prin ţinta de securitate.
6. În procesul de examinare a vulnerabilitãţilor rezultate din procesul de construcţie a produsului, evaluatorul trebuie sã identifice eventuale astfel de vulnerabilitãţi ale acestuia. Erorile identificate în procesul de evaluare a corectitudinii procesului de dezvoltare a produsului reprezintã o sursã de vulnerabilitãţi constructive. Aceastã activitate presupune examinarea erorilor, precum şi a diferitelor funcţionalitãţi introduse în fiecare etapã a dezvoltãrii produsului.
7. Examinarea uşurinţei de utilizare presupune identificarea modurilor de operare nesigure ale produsului. Prin urmare, aceastã activitate este strâns legatã de cerinţele operaţionale.
8. Activitatea de evaluare a vulnerabilitãţilor operaţionale presupune ca evaluatorul sã examineze modul de operare a produsului, pentru a identifica eventuale vulnerabilitãţi apãrute în cursul acestui proces.
9. Vulnerabilitãţile operaţionale trateazã aspecte la limita dintre mãsurile de securitate IT şi cele non-IT, cum ar fi proceduri operaţionale privind securitatea fizicã, modalitãţi nonelectronice de management al cheilor, distribuţia ecusoanelor de securitate etc. Mãsurile de securitate non-IT trebuie sã facã obiectul preocupãrilor entitãţii evaluatoare în urmãtoarele situaţii:
a) apar ca parte a documentaţiei de operare;
b) ţinta de securitate este formulatã pe baza unei politici de securitate a sistemului;
c) apar ca parte a documentaţiei produsului.
10. În procesul de analizã a vulnerabilitãţilor operaţionale ale produsului, evaluatorii trebuie sã analizeze dacã mãsurile de securitate non-IT implementate contracareazã vulnerabilitãţile constructive identificate.
11. Activitatea de verificare a cerinţelor presupune ca evaluatorul sã determine dacã ţinta de securitate defineşte în mod corect funcţiile care asigurã implementarea securitãţii. Ţinta de securitate trebuie sã identifice clar aceste funcţii, nivelul de evaluare solicitat, precum şi mãsurile de securitate implementate şi care trebuie avute în vedere în procesul de evaluare a produsului.
12. Prima etapã în procesul de dezvoltare a produsului, de la faza de cerinţe la cea de proiect de arhitecturã, prezintã o importanţã deosebitã, avându-se în vedere faptul cã asigurã corespondenţa dintre funcţiile abstracte şi componentele logice şi fizice ale produsului. În acest context, una dintre principalele activitãţi din procesul de evaluare este verificarea proiectului de arhitecturã, în urma cãreia evaluatorul decide dacã existã o separare bine definitã între funcţionalitãţile care asigurã securitatea şi celelalte funcţionalitãţi ale produsului. În acest caz, activitatea de evaluare poate fi focalizatã asupra elementelor care contribuie la asigurarea securitãţii, iar ţinta de securitate poate fi urmãritã cu uşurinţã, pe mãsurã ce proiectul este analizat mai în detaliu.
13. Activitatea de verificare a proiectului detaliat presupune analiza modului în care este respectatã politica privind separarea componentelor care asigurã securitatea de celelalte componente, precum şi verificarea faptului cã toate componentele care asigurã implementarea securitãţii sunt corect implementate.
14. Verificarea implementãrii presupune analiza modului în care sunt implementate mecanismele de asigurare a securitãţii, într-un mod mai detaliat decât în cursul activitãţii de verificare a proiectului. Analiza se bazeazã pe concluziile activitãţii de verificare a proiectului detaliat, dupã care devine posibilã testarea funcţionalã.
15. Prin activitatea de verificare a mediului de dezvoltare se analizeazã în special standardele conform cãrora este dezvoltat produsul. În cursul acestei activitãţi se analizeazã:
a) controlul configuraţiei;
b) limbajele de programare şi compilatoarele;
c) mãsurile de securitate implementate de dezvoltator.
16. Activitatea de verificare a documentaţiei de operare presupune verificarea faptului cã produsul poate fi administrat şi utilizat în acord cu obiectivele sale de securitate.
17. Verificarea mediului de operare presupune ca evaluatorul sã analizeze dacã produsul operaţional este identic cu produsul rezultat din procesul de dezvoltare şi dacã acesta poate fi operat în conformitate cu obiectivele securitãţii.
18. Testele de penetrare au rolul de a identifica eventuale vulnerabilitãţi, care pot fi exploatate în procesul de utilizare a produsului.
19. Observaţiile şi rezultatele fiecãrei activitãţi din procesul de evaluare trebuie consemnate în raportul tehnic de evaluare.
ANEXA 3
────────
la metodologie
───────────────
MODEL DE RAPORT TEHNIC DE EVALUARE (RTE)
CAP. I
Introducere
SECŢIUNEA 1
Elemente generale
1. Prezenta secţiune conţine date generale cu privire la procesul de evaluare şi trebuie sã prezinte cel puţin urmãtoarele elemente:
a) denumirea, numãrul de identificare şi versiunea/modelul produsului INFOSEC supus evaluãrii;
b) date privind dezvoltatorul produsului şi, dacã este cazul, date privind subcontractanţii care au contribuit la dezvoltarea produsului;
c) date privind solicitantul evaluãrii;
d) programarea activitãţilor aferente procesului de evaluare;
e) date cu privire la entitatea evaluatoare.
SECŢIUNEA a 2-a
Obiective
2. Prezenta secţiune trebuie sã prezinte obiectivele RTE.
3. În principal, obiectivele sunt:
a) prezentarea elementelor necesare susţinerii unei anumite concluzii cu privire la produsul supus evaluãrii;
b) susţinerea procesului de reevaluare a produsului, în cazul în care solicitantul doreşte acest lucru.
SECŢIUNEA a 3-a
Domeniu de aplicabilitate
4. Prezenta secţiune trebuie sã sublinieze faptul cã RTE se referã la întreaga activitate desfãşuratã în cursul procesului de evaluare.
5. În caz contrar, trebuie specificate motivele pentru care RTE nu acoperã întreaga activitate de evaluare.
SECŢIUNEA a 4-a
Structurã
6. Prezenta secţiune trebuie sã prezinte structura RTE.
CAP. II
Sumar
7. Prevederile prezentului capitol furnizeazã date cu privire la rezultatele evaluãrii.
8. Dispoziţiile prezentului capitol trebuie sã conţinã informaţiile generale necesare introducerii produsului INFOSEC în Catalogul naţional de pachete, produse şi profile de protecţie INFOSEC, dupã certificare.
9. Prin urmare, sumarul nu trebuie sã conţinã informaţii clasificate.
10. Prezentul capitol trebuie sã conţinã:
a) date cu privire la entitatea evaluatoare;
b) nivelul de evaluare atins efectiv;
c) numãrul de identificare şi versiunea/modelul produsului INFOSEC;
d) sumarul principalelor concluzii ale evaluãrii;
e) date cu privire la solicitantul evaluãrii;
f) scurtã descriere a produsului INFOSEC supus evaluãrii;
g) scurtã descriere a caracteristicilor de securitate ale produsului INFOSEC supus evaluãrii.
CAP. III
Descrierea produsului INFOSEC supus evaluãrii
SECŢIUNEA 1
Funcţionalitatea produsului INFOSEC
11. Prezenta secţiune trebuie sã conţinã o prezentare succintã a rolului operaţional al produsului, precum şi a funcţiunilor pentru care a fost proiectat. Descrierea trebuie sã conţinã cel puţin urmãtoarele elemente:
a) tipul de date care pot fi procesate utilizând produsul (nivel de clasificare etc.);
b) categoriile de utilizatori care vor utiliza produsul (corelat cu precizãrile de la punctul anterior).
SECŢIUNEA a 2-a
Etapele procesului de dezvoltare
12. Prezenta secţiune trebuie sã prezinte etapele parcurse în realizarea produsului.
13. De asemenea, trebuie prezentate metodologiile, tehnicile, instrumentele şi standardele relevante pentru realizarea produsului.
14. Totodatã, prezenta secţiune trebuie sã includã descrierea elementelor necesare evaluãrii puse la dispoziţia entitãţii evaluatoare de cãtre solicitant. Descrierea trebuie sã includã data la care au fost puse la dispoziţie aceste elemente şi numãrul de înregistrare cu care a fost luat în evidenţã fiecare element.
SECŢIUNEA a 3-a
Arhitectura produsului
15. Prezenta secţiune trebuie sã conţinã un sumar al proiectului general al produsului. Trebuie sã se precizeze gradul de separare între componentele care asigurã implementarea securitãţii şi celelalte componente. Secţiunea va prezenta şi modul de implementare şi distribuţia între componentele hardware, firmware şi software a elementelor care asigurã implementarea securitãţii.
16. Toate numerele modelelor/versiunilor acestor componente trebuie specificate într-o anexã la RTE (anexa C).
SECŢIUNEA a 4-a
Descrierea componentelor hardware
17. Descrierea componentelor hardware trebuie sã prezinte în detaliu toate componentele relevante pentru procesul de evaluare, la nivel de arhitecturã.
SECŢIUNEA a 5-a
Descrierea componentelor firmware
18. Descrierea componentelor firmware trebuie sã prezinte în detaliu toate componentele relevante pentru procesul de evaluare.
SECŢIUNEA a 6-a
Descrierea componentelor software
19. Descrierea componentelor software trebuie sã prezinte în detaliu toate componentele relevante pentru procesul de evaluare. Descrierea trebuie sã furnizeze legãtura dintre componentele software şi cele hardware şi firmware.
CAP. IV
Caracteristici de securitate ale produsului INFOSEC
20. Trebuie subliniat cã înţelegerea ţintei de securitate este un element esenţial pentru înţelegerea RTE. De aceea, este recomandabil ca acest capitol sã includã descrierea completã a ţintei de securitate.
21. Capitolul trebuie sã abordeze cel puţin urmãtoarele aspecte:
a) politica de securitate pentru produsul INFOSEC;
b) specificarea funcţiilor de implementare a securitãţii;
c) specificarea mecanismelor de securitate;
d) precizarea nivelului minim estimat de eficienţã a mecanismelor de securitate;
e) nivelul de evaluare solicitat.
CAP. V
Evaluarea
22. Prevederile prezentului capitol detaliazã activitãţile efectuate în procesul de evaluare, cu specificarea tuturor problemelor identificate, atât a celor de naturã tehnicã, cât şi a celor de naturã managerialã.
23. Capitolul trebuie sã conţinã date care sã sprijine activitatea comisiei de certificare de securitate, în analiza aspectelor de naturã tehnicã şi managerialã. Totodatã, datele cuprinse în acest capitol pot sã contribuie şi la eficientizarea activitãţii entitãţii evaluatoare.
SECŢIUNEA 1
Etapele evaluãrii
24. Aceastã secţiune este similarã celei în care sunt prezentate etapele procesului de dezvoltare şi trebuie sã includã date cu privire la:
a) data la care a fost demarat procesul de evaluare;
b) data la care au fost furnizate elementele necesare evaluãrii, inclusiv ţinta de securitate a produsului;
c) perioada în care au fost realizate testele de penetrare;
d) eventuale vizite efectuate la sediile dezvoltatorului sau ale utilizatorului final al produsului;
e) data la care s-au încheiat activitãţile tehnice.
25. Secţiunea trebuie sã precizeze toate metodele, tehnicile, instrumentele şi standardele utilizate în procesul de evaluare.
SECŢIUNEA a 2-a
Procedura de evaluare
26. Aceastã secţiune trebuie sã conţinã un sumar al PAE. Sumarul trebuie sã includã:
a) activitãţile desfãşurate de evaluator, conform PAE;
b) totalitatea activitãţilor desfãşurate în procesul de evaluare, cu evidenţierea activitãţilor care nu au fost cuprinse în PAE, dar au fost efectuate în practicã; va fi precizatã motivaţia existenţei acestor discrepanţe.
SECŢIUNEA a 3-a
Domeniul de aplicare a evaluãrii
27. Prezenta secţiune trebuie sã precizeze componentele care au fãcut obiectul evaluãrii, precum şi ipotezele fãcute cu privire la componentele care nu au fost examinate.
SECŢIUNEA a 4-a
Constrângeri şi ipoteze
28. Prezenta secţiune trebuie sã precizeze eventualele constrângeri asupra procesului de evaluare şi ipotezele fãcute în cursul acestui proces.
CAP. VI
Sumarul rezultatelor evaluãrii
29. Prevederile prezentului capitol trebuie sã prezinte sumarul rezultatelor evaluãrii, pentru toate activitãţile efectuate în cursul procesului.
30. Se recomandã structurarea pe secţiuni care sã corespundã fiecãreia dintre activitãţile desfãşurate.
31. Fiecare secţiune trebuie sã fie corelatã cu setul de activitãţi desfãşurate.
32. Prezentãm în continuare, cu titlu de exemplu, o listã de aspecte care fac obiectul acestui capitol:
a) Eficienţa constructivã
- Aspect 1 - Conformitatea funcţionalitãţii
- Aspect 2 - Interrelaţionarea funcţionalitãţilor
- Aspect 3 - Eficienţa mecanismelor
- Aspect 4 - Evaluarea vulnerabilitãţilor constructive
b) Eficienţa operaţionalã
- Aspect 1 - Flexibilitatea în utilizare
- Aspect 2 - Evaluarea vulnerabilitãţilor operaţionale
c) Realizarea produsului - Procesul de dezvoltare
- Etapa 1 - Cerinţe
- Etapa 2 - Proiectul arhitecturii
- Etapa 3 - Proiectul detaliat
- Etapa 4 - Implementarea
d) Realizarea produsului - Mediul de dezvoltare
- Aspect 1 - Controlul configuraţiei
- Aspect 2 - Limbaje de programare şi compilatoare
- Aspect 3 - Mãsurile de securitate implementate de cãtre dezvoltator
e) Operare - Documentaţia de operare
- Aspect 1 - Documentaţia de utilizare
- Aspect 2 - Documentaţia de administrare
f) Operare - Mediul operaţional
- Aspect 1 - Livrarea şi configurarea produsului
- Aspect 2 - Punerea în funcţiune şi operarea.
SECŢIUNEA 1
Teste de penetrare
33. Rezultatele testelor de penetrare au fost analizate separat deoarece testele de penetrare sunt de cele mai multe ori realizate ca parte a unei anumite activitãţi.
34. Prezenta secţiune trebuie sã prezinte toate opţiunile de configurare folosite în timpul testelor de penetrare.
SECŢIUNEA a 2-a
Vulnerabilitãţi exploatabile identificate
35. Prezenta secţiune trebuie sã descrie vulnerabilitãţile ce pot fi exploatate, care au fost identificate în timpul evaluãrii, precizând:
a) funcţia de implementare a securitãţii la care a fost identificatã vulnerabilitatea;
b) descrierea vulnerabilitãţii;
c) acţiunile întreprinse de evaluator în momentul identificãrii vulnerabilitãţii;
d) activitatea în cursul cãreia a fost identificatã vulnerabilitatea;
e) persoana care a identificat vulnerabilitatea (dezvoltatorul sau evaluatorul);
f) data la care a fost identificatã vulnerabilitatea;
g) dacã vulnerabilitatea a fost remediatã (se menţioneazã data) sau nu;
h) sursa generatoare a vulnerabilitãţii (dacã este posibil).
SECŢIUNEA a 3-a
Observaţii legate de vulnerabilitãţi ce nu pot fi exploatate
36. Prezenta secţiune trebuie sã descrie vulnerabilitãţile ce nu pot fi exploatate şi au fost identificate în cadrul evaluãrii (subliniindu-le pe cele rãmase în produsul operaţional).
SECŢIUNEA a 4-a
Erori identificate
37. Prezenta secţiune trebuie sã precizeze impactul pe care îl pot avea erorile identificate în cadrul procesului de evaluare.
CAP. VII
Ghid pentru reevaluare şi analizã a impactului
38. Prezentul capitol este opţional. Poate fi omis dacã solicitantul evaluãrii a declarat cã nu necesitã informaţii privind o reevaluare sau analizã a impactului.
39. Dacã va fi inclus, acest capitol trebuie sã precizeze:
a) includerea fiecãrei componente a produsului INFOSEC în una dintre urmãtoarele categorii: componente care asigurã implementarea securitãţii, componente relevante pentru securitate sau componente care nu sunt relevante pentru securitate;
b) identificarea instrumentelor de dezvoltare care sunt relevante pentru securitate;
c) modalitatea în care constrângerile sau ipotezele fãcute în procesul de evaluare pot avea impact în cazul reevaluãrii sau refolosirii produsului;
d) orice concluzii privind tehnici de evaluare sau instrumente care pot fi utile în cazul unei reevaluãri;
e) detalii de arhivare necesare reînceperii evaluãrii;
f) pregãtire specificã necesarã reevaluatorilor pentru demararea unui proces de reevaluare.
CAP. VIII
Concluzii şi recomandãri
40. Prezentul capitol trebuie sã cuprindã concluziile şi recomandãrile evaluãrii. Concluzia principalã va preciza dacã produsul îndeplineşte obiectivul de securitate stabilit şi dacã are vulnerabilitãţi ce pot fi exploatate.
41. Trebuie sã se specifice faptul cã recomandãrile se referã la componentele produsului care au fãcut obiectul evaluãrii şi cã pot exista şi alţi factori de care evaluatorii nu sunt conştienţi, iar aceşti factori pot influenţa procesul de certificare a produsului.
42. Recomandãrile pot include sugestii cãtre alte entitãţi, precum solicitantul evaluãrii sau dezvoltatorul produsului, pentru a fi înaintate comisiei de certificare de securitate.
43. Trebuie sã se specifice faptul cã rezultatele evaluãrii sunt valabile numai pentru o anumitã versiune a produsului INFOSEC, configuratã într-un anumit mod, iar comisia de certificare de securitate trebuie informatã despre orice schimbãri aduse produsului.
Anexa A - Lista elementelor necesare evaluãrii
44. Aceastã anexã trebuie sã identifice, cu numerele versiunii şi datele la care au fost recepţionate, toate elementele necesare evaluãrii sau se face o referire la lista elementelor.
Anexa B - Lista de acronime/Glosar de termeni
45. Aceastã anexã trebuie sã explice toate acronimele şi abrevierile folosite în RTE. De asemenea, trebuie sã defineascã termenii specifici utilizaţi.
Anexa C - Configuraţia evaluatã
46. Configuraţiile produsului INFOSEC examinate în cadrul evaluãrii (în special configuraţii folosite la testele de penetrare, verificare a fiabilitãţii) trebuie identificate clar.
47. Trebuie precizate orice presupuneri fãcute sau configuraţii care nu au fost luate în considerare.
Descrierea componentelor hardware
48. Descrierea componentelor hardware trebuie sã furnizeze informaţii despre configuraţie, privind toate componentele la nivel arhitectural ce sunt relevante pentru evaluare şi, în consecinţã, pentru implementarea securitãţii.
Descrierea componentelor firmware
49. Descrierea componentelor firmware trebuie sã furnizeze informaţii despre configuraţie, despre toate componentele care sunt relevante pentru procesul de evaluare şi, în consecinţã, pentru implementarea securitãţii.
Descrierea componentelor software
50. Descrierea componentelor software trebuie sã furnizeze informaţii despre configuraţie privind pãrţi ale aplicaţiilor software utilizate de produsul INFOSEC care sunt relevante pentru procesul de evaluare şi, în consecinţã, pentru implementarea securitãţii.
Anexa D - Rapoartele activitãţilor de evaluare
51. Aceastã anexã nu este necesarã dacã toate rapoartele de activitate sunt incluse în cap. 6 al RTE.
52. Dacã este prezentã, aceastã anexã trebuie sã cuprindã înregistrãri ale tuturor activitãţilor de evaluare (incluzând rezultatele testelor efectuate, tehnici şi instrumente utilizate).
Anexa E - Probleme identificate
53. Aceastã anexã trebuie sã cuprindã rapoarte cu privire la toate problemele identificate în cursul procesului de evaluare.
54. Rapoartele pot fi emise şi înainte de finalizarea evaluãrii şi trebuie sã conţinã cel puţin urmãtoarele elemente:
a) numãrul şi versiunea produsului supus evaluãrii;
b) activitatea în cursul cãreia a fost identificatã problema;
c) descrierea problemei identificate.
ANEXA 4
───────
la metodologie
───────────────
Elemente ale raportului privind certificarea
Un raport privind certificarea trebuie sã includã cel puţin urmãtoarele elemente:
a) Introducere:
- date generale cu privire la produsul INFOSEC supus evaluãrii.
b) Rezumat:
- detalii cu privire la entitatea de evaluare;
- identificarea completã a produsului INFOSEC supus evaluãrii, inclusiv a codului de identificare, versiunii etc.;
- sumarul concluziilor formulate de evaluator;
- date privind dezvoltatorul şi, dacã este cazul, date privind subcontractanţii acestuia care au contribuit la dezvoltarea produsului;
- date privind solicitantul certificãrii;
- nivelul de evaluare atins efectiv.
c) Prezentarea produsului:
- descrierea produsului INFOSEC, în configuraţia supusã evaluãrii;
- descrierea hardware;
- descrierea firmware;
- descrierea software;
- descrierea documentaţiei produsului.
d) Evaluarea:
- descrierea sumarã a ţintei de securitate, care sã cuprindã şi descrierea caracteristicilor de securitate ale produsului INFOSEC;
- elemente de identificare ale RTE;
- sumarul principalelor concluzii formulate de entitatea de evaluare.
e) Certificarea:
- propuneri referitoare la luarea unei decizii cu privire la certificarea produsului INFOSEC;
- specificarea eventualelor restricţii care trebuie avute în vedere în procesul de utilizare a produsului (de exemplu: limitarea nivelului de clasificare a informaţiilor, utilizare în medii operaţionale specifice etc.).
ANEXA 5
───────
la metodologie
───────────────
BIBLIOGRAFIE
1. <>Standardele naţionale de protecţie a informaţiilor clasificate în România, aprobate prin <>Hotãrârea Guvernului nr. 585/2002 , publicatã în Monitorul Oficial al României, Partea I, nr. 485 din 5 iulie 2002, cu modificãrile şi completãrile ulterioare.
2. <>Normele privind protecţia informaţiilor clasificate ale Organizaţiei Tratatului Atlanticului de Nord în România, aprobate prin <>Hotãrârea Guvernului nr. 353/2002 , publicatã în Monitorul Oficial al României, Partea I, nr. 315 din 13 mai 2002, cu modificãrile ulterioare.
3. Metodologia de acreditare a entitãţilor pentru evaluarea produselor de securitate IT şi a sistemelor informatice şi de comunicaţii - INFOSEC 12, aprobatã prin <>Ordinul directorului general al Oficiului Registrului Naţional al Informaţiilor Secrete de Stat nr. 167/2006 , publicat în Monitorul Oficial al României, Partea I, nr. 223 din 10 martie 2006.
4. Guidelines for the Evaluation and Certification of ADP Systems and Networks and Computer Security (COMPUSEC) Products, AC/35-N/275.
5. Procedure CER/P/01.1 - Certification of the security provided by IT products and systems, February 9, 2004 - Secretariat General de la Defense Nationale, France.
6. Information Technology Security Evaluation Manual (ITSEM), version 1.0, Commission of the European Communities.
7. Scheme overview, draft 0.3, April 15, 2005 - Swedish Certification Body for IT Security.
8. Evaluation and Certification, draft 0.9, April 15, 2005 - Swedish Certification Body for IT Security.
9. Common Criteria Evaluation and Validation Scheme For Information Technology Security, Guidance to Validators of IT Security Evaluations, Version 1.0, February 2002, National Institute for Standards and Technologies, U.S.
10. Common Criteria Evaluation and Validation Scheme Policy Letter - National Information Assurance Partnership, U.S.
11. Information Technology Security Testing - Common Criteria, April 1999, Version 1.1, U.S. Department of Commerce.
12. Guidelines for Evaluation Work Program (EWP), January 14, 1998, JEIDA Japan.
_________