Kontrola niezadeklarowanych zdolności

Maksym Repin
Specjalista JSC „Koncern „BEGA”

Anastazja Sakulina
Specjalista JSC „Koncern „BEGA”

Obecnie, ze względu na wzrost liczby wycieków informacje poufne(CI) główne pytanie dotyczy jego niezawodnej ochrony.

W odróżnieniu od tajemnicy państwowej i danych osobowych, dokumenty regulacyjne z zakresu ochrony IK mają charakter doradczy, w związku z czym pojawia się naturalne pytanie: czy należy ich przestrzegać, czy nie?

Rozważmy potrzebę i wykonalność certyfikacji sprzętu zabezpieczającego CI zgodnie z poziomami kontroli nad brakiem niezadeklarowanych zdolności (NDC).

Poziomy kontroli pod kątem braku materiałów niezgodnych

Istnieją cztery poziomy kontroli nieobecności NDV. Aby chronić CI, zwykle stosuje się poziom 4, ale można również zastosować poziom 3, który obejmuje dokładniejszą analizę braku NDV.

Zasadnicza różnica pomiędzy wskazanymi poziomami kontroli polega na tym, że na poziomie 4. realizowane są czynności wyłącznie w zakresie statycznej analizy oprogramowania, a na poziomie 3. kontroli prowadzone są także czynności w zakresie analizy dynamicznej. Proces analizy statycznej na tych poziomach różni się wolumenem regulowanych operacji technologicznych. Tym samym deweloper, certyfikując swój produkt na poziomie 3, uzyskuje dostęp do rynku także środków ochrony tajemnicy państwowej.

Często słyszymy następujące argumenty przemawiające za certyfikacją:

• certyfikowane oprogramowanie prawidłowo realizuje swoje funkcje bezpieczeństwa informacji;
• Certyfikowane oprogramowanie gwarantuje brak wbudowanych mechanizmów, które mogłyby zaszkodzić informacjom klientów.

W praktyce posiadanie certyfikatu oprogramowania nie zawsze gwarantuje zgodność z tymi stwierdzeniami.

Jeśli weźmiemy pod uwagę produkty oferowane na rynku krajowym i posiadające certyfikat, to często prezentują się one raczej opłakanym widokiem, ponieważ zwykle mają pełną gamę błędów oprogramowania i nie zapewniają ani łatwości obsługi, ani elastyczności ustawień.

W duże firmy znajdowanie błędów w programach i testowanie ich oddzielny etap, zbudowane według ściśle ustalonych metod i przeprowadzone duża liczba pracownicy. Dodatkowa kontrola podczas certyfikacji, wymagającej długiego okresu czasu i znaczącej koszty finansowe, daje konkurentom jedynie przewagę, zmniejszając zyski firmy i znacznie zwiększając koszt produktu końcowego ze względu na koszty certyfikacji.

Na rynku wolnego oprogramowania funkcje te pełnią entuzjaści. Często posiadają oni bardzo głęboką wiedzę w tym zakresie, a ich liczba jest znacznie większa niż personelu jakiegokolwiek laboratorium. Dzięki temu można dokładnie przejrzeć cały kod i naprawić wszystkie słabe punkty.

W w tej chwili laboratoria badawcze, które przeprowadzają certyfikację na brak NDV, nie mają ani ludzi, ani zasoby techniczne, pozwalając na odpowiednim poziomie iw tak szybko, jak to możliwe przeprowadzamy procedury weryfikacyjne dla złożonego oprogramowania.

Innym problemem jest to, że aktualizacje oprogramowania i poprawki stanowią naruszenie warunków wydanego certyfikatu i wymagają powtórzyć procedurę sprawdza. Podobna sytuacja ma miejsce, gdy ważność certyfikatu wygasła. Czy istnieją nowe wytyczne dotyczące monitorowania braku NDV ustalona procedura potwierdzanie i odnawianie certyfikatu, które opiera się na analizie zgodności certyfikowanych właściwości nowo dostarczonego produktu z właściwościami starej certyfikowanej wersji, już nie działa.

Paradoks problemu posiadania zakładek programowych (SW) w produkcie

Paradoks ten polega na tym, że PP może nie być obecny w oprogramowaniu przed certyfikacją, ale pojawić się po niej. Iluzja uzyskania certyfikatu może znacząco zmniejszyć czujność programistów i doprowadzić do nieprzewidywalnych konsekwencji dla klienta. Organizacje indywidualne Korzystając z tych zakładek, będą mogli ukryte monitorowanie i przechwytywanie wszelkich informacji firmowych oraz wykorzystywanie ich według własnego uznania. Jeśli te zakładki zostaną zidentyfikowane, nie tylko użytkownik końcowy, ale także spółkę deweloperską, która otrzyma znaczący cios w swój wizerunek, reputację i osłabi swoją pozycję na rynku. Klient będzie zmuszony przebudować cały system ochrony od nowa, a to będzie wiązać się z nowymi kosztami.

System regulacji bezpieczeństwa informacji jest bardzo w dobry sposób w celu ustalenia określonego poziomu jakości produktu, nie powinno to jednak zakłócać konkurencji i stanowić narzędzie regulacji rynku.

Analiza obecnej sytuacji pokazuje, że certyfikacja produktów służących do ochrony informacji poufnych nie jest wystarczająco istotna, ponieważ stwarza niepotrzebne złudzenia bezpieczeństwa. Przy wyborze oprogramowanie Aby się zabezpieczyć, musisz przede wszystkim kierować się recenzjami ekspertów i reputacją programistów.

W tej chwili, aby zbudować naprawdę niezawodny system ochrony, lepiej zainwestować pieniądze w kompetentny i sprawdzony administratorzy systemu i konsultanci. Ich wiedza i doświadczenie pomogą Państwu wybrać najbardziej niezawodne i odpowiednie rozwiązania dla konkretnej firmy.

Artykuły na ten temat

W wymaganiach bezpieczeństwa informacji podczas projektowania systemy informacyjne wskazano cechy charakteryzujące stosowane środki bezpieczeństwa informacji. Określają je różne akty organów regulacyjnych w zakresie bezpieczeństwa bezpieczeństwo informacji, w szczególności - FSTEC i FSB Rosji. Jakie są klasy bezpieczeństwa, rodzaje i rodzaje sprzętu ochronnego, a także gdzie można dowiedzieć się więcej na ten temat, opisano w artykule.

Wstęp

Obecnie kwestie zapewnienia bezpieczeństwa informacji są przedmiotem szczególnej uwagi, gdyż wdrażane wszędzie technologie bez zapewnienia bezpieczeństwa informacji stają się źródłem nowych, poważnych problemów.

Rosyjska FSB informuje o powadze sytuacji: wielkość szkód wyrządzonych przez napastników na przestrzeni kilku lat na całym świecie wahała się od 300 miliardów dolarów do 1 biliona dolarów. Według przekazanych informacji Prokurator Generalny Federacji Rosyjskiej, tylko w pierwszej połowie 2017 roku w Rosji wzrosła liczba przestępstw z tego zakresu wysoka technologia wzrosła sześciokrotnie całkowita kwota szkody przekroczyły 18 mln dolarów. W 2017 r. na całym świecie odnotowano wzrost liczby ataków ukierunkowanych w sektorze przemysłowym. W szczególności w Rosji wzrost liczby ataków w porównaniu z 2016 rokiem wyniósł 22%.

Technologie informacyjne zaczęto wykorzystywać jako broń do celów wojskowo-politycznych, terrorystycznych i do ingerencji w sprawy wewnętrzne suwerenne państwa a także za popełnienie innych przestępstw. Federacja Rosyjska opowiada się za utworzeniem międzynarodowego systemu bezpieczeństwa informacji.

Na terytorium Federacja Rosyjska właściciele informacji i operatorzy systemów informatycznych mają obowiązek blokowania prób nieuprawnionego dostępu do informacji, a także monitorowania stanu bezpieczeństwa infrastruktury informatycznej na na bieżąco. Jednocześnie ochronę informacji zapewnia się poprzez podejmowanie różnorodnych działań, w tym technicznych.

Narzędzia bezpieczeństwa informacji, czyli systemy ochrony informacji, zapewniają ochronę informacji w systemach informatycznych, które w istocie stanowią zbiór informacji przechowywanych w bazach danych, technologia informacyjna, zapewnienia jego przetwarzania oraz środki techniczne.

Nowoczesne systemy informacyjne charakteryzują się wykorzystaniem różnych platform sprzętowych i programowych, terytorialnym rozmieszczeniem komponentów, a także interakcją z otwartymi sieciami danych.

Jak chronić informacje w takich warunkach? Nałożone są odpowiednie wymagania upoważnione organy w szczególności FSTEC i FSB Rosji. W ramach artykułu postaramy się odzwierciedlić główne podejścia do klasyfikacji systemów bezpieczeństwa informacji, biorąc pod uwagę wymagania tych regulatorów. Inne sposoby opisu klasyfikacji systemów bezpieczeństwa informacji odzwierciedlone w dokumenty regulacyjne wydziały rosyjskie, a także organizacje zagraniczne i agencje wykraczają poza to tego artykułu i nie są dalej rozpatrywane.

Artykuł może być przydatny dla początkujących specjalistów w dziedzinie bezpieczeństwa informacji jako źródło ustrukturyzowanej informacji na temat metod klasyfikacji bezpieczeństwa informacji na podstawie wymagań FSTEC z Rosji(w większym stopniu) i w skrócie FSB Rosji.

Strukturą ustalającą procedurę i koordynującą zapewnianie niekryptograficznych metod bezpieczeństwa informacji jest FSTEC Rosji (dawniej Państwowa Komisja Techniczna przy Prezydencie Federacji Rosyjskiej, Państwowa Komisja Techniczna).

Jeśli czytelnik kiedykolwiek widział Państwowy Rejestr Certyfikowanych Narzędzi Bezpieczeństwa Informacji tworzony przez FSTEC Rosji, to z pewnością zwrócił uwagę na obecność w części opisowej celu systemu ochrony informacji takich zwrotów jak „RD SVT klasa”, „poziom braku niezgodności z danymi dotyczącymi niezgodności” itp. (Rysunek 1).

Rysunek 1. Fragment rejestru certyfikowanych urządzeń ochrony informacji

Klasyfikacja narzędzi bezpieczeństwa informacji kryptograficznej

FSB Rosji zdefiniowała klasy systemów ochrony informacji kryptograficznej: KS1, KS2, KS3, KV i KA.

Do głównych cech sprzętu bezpieczeństwa informacji klasy KS1 zalicza się jego odporność na ataki przeprowadzane z zewnątrz kontrolowany obszar. Oznacza to, że tworzenie metod ataku, ich przygotowanie i wdrażanie odbywa się bez udziału specjalistów z zakresu opracowywania i analizy bezpieczeństwa informacji kryptograficznej. Zakłada się, że informacje o systemie, w którym stosowane są określone systemy bezpieczeństwa informacji, można pozyskać z otwartych źródeł.

Jeżeli system bezpieczeństwa informacji kryptograficznej jest w stanie wytrzymać ataki blokowane za pomocą klasy KS1, a także te przeprowadzane na obszarze kontrolowanym, to takie bezpieczeństwo informacji odpowiada klasie KS2. Możliwe jest na przykład, że podczas przygotowywania ataku informacja o środki fizyczne ochrona systemów informatycznych, udostępnienie obszaru kontrolowanego itp.

Jeśli możliwe jest przeciwstawienie się atakom, jeśli masz fizyczny dostęp do funduszy technologia komputerowa przy zainstalowanych systemach bezpieczeństwa informacji kryptograficznej mówią o zgodności tych środków z klasą KS3.

Jeśli bezpieczeństwo informacji kryptograficznej oprze się atakom, które powstały przy udziale specjalistów z zakresu rozwoju i analizy określone fundusze, w tym ośrodków badawczych, było możliwe do przeprowadzenia badania laboratoryjne zatem środki ochrony o czym mówimy na zgodność z klasą HF.

Jeśli w opracowywaniu metod ataku zajmowali się specjaliści z zakresu wykorzystania oprogramowania systemu NDV, odpowiedni dokumentacja projektowa i istniał dostęp do jakichkolwiek elementów sprzętowych bezpieczeństwa informacji kryptograficznej, wówczas ochronę przed takimi atakami można zapewnić za pomocą klasy KA.

Klasyfikacja środków ochrony podpisu elektronicznego

Oznacza podpis elektroniczny w zależności od odporności na ataki zwyczajowo porównuje się je z klasami: KS1, KS2, KS3, KV1, KV2 i KA1. Klasyfikacja ta jest podobna do tej omówionej powyżej w odniesieniu do bezpieczeństwa informacji kryptograficznej.

Wnioski

W artykule zbadano niektóre metody klasyfikacji systemów bezpieczeństwa informacji w Rosji, których podstawą jest ramy regulacyjne regulatorów w zakresie bezpieczeństwa informacji. Rozważane możliwości klasyfikacji nie są wyczerpujące. Mamy jednak nadzieję, że zaprezentowane podsumowanie informacji pozwoli początkującemu specjaliście w dziedzinie bezpieczeństwa informacji szybko się poruszać.

Prawdziwy Dokument zawierający wytyczne(RD) ustala klasyfikację oprogramowania (zarówno krajowego, jak i importowanego) narzędzi bezpieczeństwa informacji (IS), w tym wbudowanych w ogólne oprogramowanie systemowe i aplikacyjne, według poziomu kontroli nad brakiem w nim niezadeklarowanych możliwości.

Dokument nie dotyczy oprogramowania narzędzi do ochrony informacji kryptograficznej.

Poziom kontroli określa się poprzez spełnienie zbioru wymagań określonych w niniejszym RD :

do składu i treść dokumentacji, złożone przez wnioskodawcę w celu przetestowania oprogramowania chroniącego informacje

Wytyczne zostały opracowane w uzupełnieniu do RD „Infrastruktura komputerowa. Ochrona przed nieuprawnionym dostępem do informacji. Wskaźniki zabezpieczenia przed nieuprawnionym dostępem do informacji”, M., Wydawnictwo Wojskowe, 1992,

RD „Systemy zautomatyzowane. Ochrona przed nieuprawnionym dostępem do informacji. Klasyfikacja systemów zautomatyzowanych i wymagania ochrony informacji”, M., Wydawnictwo Wojskowe,

1992 i RD „Zaplecze komputerowe. Zapory ogniowe. Ochrona przed nieuprawnionym dostępem do informacji. Wskaźniki bezpieczeństwa przed nieuprawnionym dostępem do informacji”, M., 1997.

Dokument przeznaczony jest dla specjalistów laboratoria badawcze, klientów, twórców oprogramowania zabezpieczającego informacje przy jednoczesnym monitorowaniu go pod kątem braku niezadeklarowanych możliwości.

1. Postanowienia ogólne

1.1. Klasyfikacja dotyczy oprogramowania zaprojektowanego w celu ochrony informacji zastrzeżonych.

1.2. Zainstalowany cztery poziomy kontroli brak niezadeklarowanych zdolności. Każdy poziom charakteryzuje się pewnym minimalnym zestawem wymagań.

1.3. W przypadku oprogramowania służącego do ochrony informacji, przypisywany tajemnica państwowa, należy zapewnić poziom kontroli nie niższy niż trzeci.

1.4 . Bardzo wysoki poziom kontrola – Pierwszy , wystarczające dla oprogramowania służącego do ochrony informacji sklasyfikowanych jako „OV”.

Drugi poziom kontroli wystarczające dla oprogramowania służącego do ochrony informacji oznaczonych „CC”.

Trzeci poziom kontroli wystarczający dla oprogramowania służącego do ochrony informacji oznaczonych literą „C”.

1.5 Bardzo niski poziom kontrola - czwarty , wystarczające dla oprogramowania służącego do ochrony poufny informacja.

2. Terminy i definicje

2.1. Niezadeklarowane możliwości - funkcjonalności oprogramowania, które nie są opisane lub nie odpowiadają opisanym w dokumentacji, których użycie może naruszyć poufność, dostępność lub integralność przetwarzanych informacji. Implementacją niezadeklarowanych możliwości są w szczególności zakładki programowe.

2.6. Rzeczywista trasa wykonania obiektów funkcjonalnych to sekwencja obiektów funkcjonalnych faktycznie wykonanych, kiedy pewne warunki(dane wejściowe).

Ochrona przed nieuprawnionym dostępem do informacji Część 1. Oprogramowanie zabezpieczające informacje

Klasyfikacja według poziomu kontroli braku niezadeklarowanych zdolności

Zatwierdzony decyzją Prezydenta Państwa komisja techniczna na mocy Prezydenta Federacji Rosyjskiej z dnia 4 czerwca 1999 r. N 114

Niniejsze wytyczne (RD) ustanawiają klasyfikację oprogramowania (zarówno krajowego, jak i importowanego) narzędzi bezpieczeństwa informacji (IS), w tym wbudowanych w ogólne oprogramowanie systemowe i aplikacyjne, zgodnie z poziomem kontroli nad brakiem w nim niezadeklarowanych możliwości.

Dokument nie dotyczy oprogramowania narzędzi do ochrony informacji kryptograficznej.

Poziom kontroli wyznaczany jest poprzez spełnienie zbioru wymagań określonych w niniejszym RD, nałożonych przez:
- do składu i zawartości dokumentacji przedłożonej przez wnioskodawcę w celu przetestowania oprogramowania do ochrony informacji;
- do treści testów.

Wytyczne opracowano w celu uzupełnienia:
- RD „Zaplecze komputerowe. Ochrona przed nieuprawnionym dostępem do informacji. Wskaźniki zabezpieczenia przed nieuprawnionym dostępem do informacji”, M., Wydawnictwo Wojskowe, 1992;
- RD „Systemy zautomatyzowane. Ochrona przed nieuprawnionym dostępem do informacji. Klasyfikacja systemy automatyczne i wymagania ochrony informacji”, M., Wydawnictwo Wojskowe, 1992;
- RD „Zaplecze komputerowe. Zapory ogniowe. Ochrona przed nieuprawnionym dostępem do informacji. Wskaźniki zabezpieczenia przed nieuprawnionym dostępem do informacji”, M., 1997.

Dokument przeznaczony jest dla specjalistów laboratoriów badawczych, klientów i twórców oprogramowania zabezpieczającego informacje podczas monitorowania go pod kątem braku niezadeklarowanych możliwości.

1. POSTANOWIENIA OGÓLNE

1.1. Klasyfikacja dotyczy oprogramowania zaprojektowanego w celu ochrony informacji zastrzeżonych.

1.2. Ustanawia się cztery poziomy kontroli braku niezadeklarowanych zdolności. Każdy poziom charakteryzuje się pewnym minimalnym zestawem wymagań.

1.3. W przypadku oprogramowania służącego do ochrony informacji objętych tajemnicą państwową należy zapewnić poziom kontroli co najmniej trzeci.

1.4. Najwyższy poziom kontroli to pierwszy, wystarczający dla oprogramowania służącego do ochrony informacji sklasyfikowanych jako „OV”.

Drugi poziom kontroli jest wystarczający w przypadku oprogramowania służącego do ochrony informacji oznaczonych „CC”.

Trzeci poziom kontroli jest wystarczający w przypadku oprogramowania służącego do ochrony informacji sklasyfikowanych jako „C”.

1.5 Najniższy poziom kontroli to czwarty, wystarczający dla oprogramowania służącego do ochrony informacji poufnych.

2. TERMINY I DEFINICJE

2.1. Niezadeklarowane możliwości to funkcjonalności oprogramowania, które nie są opisane lub nie odpowiadają opisanym w dokumentacji, których wykorzystanie może naruszyć poufność, dostępność lub integralność przetwarzanych informacji.

Implementacją niezadeklarowanych możliwości są w szczególności zakładki programowe.

2.2. Zakładki oprogramowania to celowo dodane do oprogramowania obiekty funkcjonalne, które pod pewnymi warunkami (dane wejściowe) inicjują wykonanie funkcji oprogramowania nieopisanych w dokumentacji, prowadząc do naruszenia poufności, dostępności lub integralności przetwarzanych informacji.

2.3. Obiekt funkcjonalny to element programu realizujący działania mające na celu implementację kompletnego fragmentu algorytmu programu.

Obiektami funkcjonalnymi mogą być procedury, funkcje, gałęzie, operatory itp.

2.4. Obiekt informacyjny- element programu zawierający fragmenty informacji krążących w programie. W zależności od języka programowania jako obiekty informacyjne mogą to być zmienne, tablice, rekordy, tabele, pliki, fragmenty BARAN itp.

2.5. Droga wykonania obiektów funkcjonalnych to określona przez algorytm sekwencja wykonanych obiektów funkcjonalnych.

2.6. Rzeczywista droga wykonania obiektów funkcjonalnych to sekwencja obiektów funkcjonalnych, które są faktycznie wykonywane w określonych warunkach (dane wejściowe).

2.7. Trasa krytyczna dla realizacji obiektów funkcjonalnych to trasa, podczas której istnieje możliwość niekontrolowanego naruszenia ustalone zasady przetwarzanie obiektów informacyjnych.

2.8. Analiza statyczna kodów źródłowych programu - zestaw metod monitorowania (nie)zgodności zaimplementowany i zadeklarowany w dokumentacji funkcjonalność Oprogramowanie oparte na analiza strukturalna i rozkład kodów źródłowych programów.

2.9. Analiza dynamiczna kodów źródłowych programów to zestaw metod monitorowania (nie)zgodności funkcjonalności oprogramowania zaimplementowanych i zadeklarowanych w dokumentacji, w oparciu o identyfikację rzeczywistych tras wykonania obiektów funkcjonalnych z późniejszym porównaniem z trasami zbudowanymi w procesie analizy statycznej .

3. WYMOGI DOTYCZĄCE POZIOMU ​​KONTROLI
3.1. LISTA WYMAGAŃ

Tabela 1

Oznaczenia
„-” - brak wymagań dla ten poziom;
„+” - nowy lub dodatkowe wymagania;
"=" - wymagania są takie same jak wymagania poprzedniego poziomu.

3.2. WYMAGANIA DLA CZWARTEGO POZIOMU ​​KONTROLI

3.2.1. Kontrola składu i zawartości dokumentacji

Dokumentacja składana przez wnioskodawcę musi zawierać:

Specyfikacja (GOST 19.202-78), zawierająca informacje o składzie oprogramowania i dokumentacji do niego;

Opis programu (GOST 19.402-78), zawierający podstawowe informacje o składzie (ze wskazaniem sum kontrolnych plików wchodzących w skład oprogramowania), struktura logiczna i środowiska działania oprogramowania, a także opis metod, technik i zasad obsługi urządzeń technologicznych przy tworzeniu oprogramowania;

Opis aplikacji (GOST 19.502-78), zawierający informacje o przeznaczeniu oprogramowania, zakresie zastosowania, zastosowanych metodach, klasie zadań do rozwiązania, ograniczeniach aplikacji, minimalnej konfiguracji sprzętu, środowisku operacyjnym i procedurze operacyjnej.

Teksty źródłowe programów (GOST 19.401-78) zawartych w oprogramowaniu.

W przypadku importowanego oprogramowania skład dokumentacji może różnić się od wymaganej, ale treść musi spełniać wymagania określonych GOST.

3.2.2. Monitorowanie stanu początkowego oprogramowania

Kontrola polega na rejestracji stanu początkowego oprogramowania i porównaniu uzyskanych wyników z podanymi w dokumentacji.

Wynikiem monitorowania stanu początkowego oprogramowania powinny być obliczone unikalne wartości sum kontrolnych modułów obciążeniowych i kodów źródłowych programów zawartych w oprogramowaniu.

Dla każdego pliku zawartego w oprogramowaniu należy obliczyć sumy kontrolne.

3.2.3. Analiza statyczna kodów źródłowych programów

Analiza statyczna kodów źródłowych programu powinna obejmować następujące operacje technologiczne:
- kontrola kompletności i braku redundancji tekstów źródłowych oprogramowania na poziomie pliku;
- kontrola zgodności tekstów źródłowych oprogramowania z jego kodem obiektowym (bootowym).

3.2.4. Raportowanie

Po zakończeniu badań sporządzany jest protokół (protokół) zawierający wyniki:
- monitorowanie stanu początkowego oprogramowania;
- kontrola kompletności i braku redundancji tekstów źródłowych kontrolowanego oprogramowania na poziomie plików;
- kontrola zgodności tekstów źródłowych z kodem obiektowym (bootowym).

3.3 WYMOGI DLA TRZECIEGO POZIOMU ​​KONTROLI

3.3.1. Kontrola składu i zawartości dokumentacji

Wymagania w pełni obejmują podobne wymagania dla czwartego poziomu kontroli.

Dodatkowo należy przedstawić „Notę wyjaśniającą” (GOST 19.404-79), zawierającą podstawowe informacje o przeznaczeniu komponentów zawartych w oprogramowaniu, parametrach przetwarzanych zbiorów danych (podschematy baz danych), wygenerowanych kodach powrotu, opis stosowanych zmiennych, działających algorytmów itp.

3.3.2. Monitorowanie stanu początkowego oprogramowania

Wymagania w pełni obejmują podobne wymagania dla czwartego poziomu kontroli.

3.3.3.Analiza statyczna kodów źródłowych programów

Oprócz podobnych wymagań dla czwartego poziomu kontroli, dodatkowe następujące wymagania:
- kontrola kompletności i braku redundancji tekstów źródłowych oprogramowania na poziomie obiektów funkcjonalnych (procedur);
- kontrola połączeń obiektów funkcjonalnych (moduły, procedury, funkcje) do zarządzania;
- kontrola połączeń obiektów funkcjonalnych (moduły, procedury, funkcje) zgodnie z informacją;
- kontrola obiektów informacyjnych różne typy(na przykład zmienne lokalne, zmienne globalne, zmienne zewnętrzne itp.);
- utworzenie listy tras wykonania obiektów funkcjonalnych (procedury, funkcje).

3.3.4. Dynamiczna analiza kodów źródłowych programów

Analiza dynamiczna kodów źródłowych programu powinna obejmować następujące operacje technologiczne:
- kontrola wykonania obiektów funkcjonalnych (procedury, funkcje);
- porównanie rzeczywistych tras wykonania obiektów funkcjonalnych (procedur, funkcji) z trasami zbudowanymi w procesie analizy statycznej.

3.3.5. Raportowanie

Oprócz podobnych wymagań dla czwartego poziomu kontroli, raport (protokół) musi dodatkowo zawierać wyniki:
- kontrola kompletności i braku redundancji tekstów źródłowych kontrolowanego oprogramowania na poziomie obiektów funkcjonalnych (procedur);
- kontrola połączeń obiektów funkcjonalnych (moduły, procedury, funkcje) do zarządzania;
- kontrola połączeń obiektów funkcjonalnych (moduły, procedury, funkcje) zgodnie z informacją;
- kontrola obiektów informacyjnych różnego typu (na przykład zmiennych lokalnych, zmiennych globalnych, zmiennych zewnętrznych itp.);
- utworzenie listy tras wykonania obiektów funkcjonalnych (procedury, funkcje);
- monitorowanie wykonania obiektów funkcjonalnych (procedury, funkcje);
- porównanie rzeczywistych tras wykonania obiektów funkcjonalnych (procedur, funkcji) z trasami zbudowanymi w procesie analizy statycznej.

3.4. WYMAGANIA DLA DRUGIEGO POZIOMU ​​KONTROLI

3.4.1. Kontrola składu i zawartości dokumentacji

3.4.2. Monitorowanie stanu początkowego oprogramowania

Wymagania w pełni obejmują podobne wymagania dla trzeciego poziomu kontroli.

3.4.3. Analiza statyczna kodów źródłowych programów

- kontrola kompletności i braku redundancji tekstów źródłowych kontrolowanego oprogramowania na poziomie obiektów funkcjonalnych (funkcji);
- syntaktyczna kontrola obecności określonych struktur w tekstach źródłowych oprogramowania z listy (bazy) potencjalnie niebezpiecznych konstrukcje programu;
- utworzenie wykazu tras realizacji obiektów funkcjonalnych (oddziałów);
- analiza tras krytycznych realizacji obiektów funkcjonalnych (procedur, funkcji) dla określonych przez eksperta list obiektów informacyjnych;
- konstruowanie schematów blokowych, diagramów itp. z tekstów źródłowych sterowanego oprogramowania, a następnie analiza porównawcza algorytmu działania obiektów funkcjonalnych (procedury, funkcje) z algorytmem działania podanym w „Nocie objaśniającej”.

3.4.4. Dynamiczna analiza kodów źródłowych programów

Oprócz podobnych wymagań dla trzeciego poziomu kontroli dodatkowo nałożone są następujące wymagania:
- kontrola realizacji obiektów funkcjonalnych (oddziałów);
- porównanie rzeczywistych tras realizacji obiektów funkcjonalnych (odgałęzień) z trasami zbudowanymi w procesie analizy statycznej

3.4.5 Raportowanie

Oprócz podobnych wymagań dla trzeciego stopnia kontroli, raport (protokół) musi dodatkowo zawierać wyniki:
- kontrola kompletności i braku redundancji tekstów źródłowych kontrolowanego oprogramowania na poziomie obiektów funkcjonalnych (funkcji);
- syntaktyczna kontrola obecności określonych struktur w tekstach źródłowych oprogramowania z listy (bazy) potencjalnie niebezpiecznych struktur;
- generowanie listy tras realizacji obiektów funkcjonalnych (oddziałów);
- analiza tras krytycznych realizacji obiektów funkcjonalnych (procedur, funkcji) dla określonych przez eksperta list obiektów informacyjnych;
- budowanie schematów blokowych, diagramów itp. z tekstów źródłowych kontrolowanego oprogramowania, a następnie analiza porównawcza algorytmu działania obiektów funkcjonalnych (procedury, funkcje) z algorytmem działania podanym w „Nocie objaśniającej”;
- monitorowanie realizacji obiektów funkcjonalnych (oddziałów);
- porównanie rzeczywistych tras realizacji obiektów funkcjonalnych (odgałęzień) z trasami zbudowanymi w procesie analizy statycznej.

3.5. WYMOGI DLA PIERWSZEGO POZIOMU ​​KONTROLI

3.5.1. Kontrola składu i zawartości dokumentacji

3.5.2. Monitorowanie stanu początkowego oprogramowania

Wymagania w pełni obejmują podobne wymagania dla drugiego poziomu kontroli.

3.5.3. Analiza statyczna kodów źródłowych programów

Oprócz podobnych wymagań dla drugiego poziomu kontroli dodatkowo nałożone są następujące wymagania:
- kontrola zgodności tekstów źródłowych oprogramowania z jego kodem obiektowym (bootowym) przy użyciu certyfikowanych kompilatorów;
- semantyczna kontrola obecności określonych struktur w tekstach źródłowych oprogramowania z listy (bazy) potencjalnie niebezpiecznych konstrukcji.

3.5.4. Dynamiczna analiza kodów źródłowych programów

Wymagania w pełni obejmują podobne wymagania dla drugiego poziomu kontroli.

3.5.5. Raportowanie

Oprócz podobnych wymagań dla drugiego stopnia kontroli, raport (protokół) musi dodatkowo zawierać wyniki:
- monitorowanie zgodności tekstów źródłowych oprogramowania z jego kodem obiektowym (rozruchowym) za pomocą certyfikowanych kompilatorów;
- semantyczna kontrola obecności określonych struktur w tekstach źródłowych oprogramowania z listy (bazy) potencjalnie niebezpiecznych konstrukcji.

Dokument zawierający wytyczne

Ochrona przed nieuprawnionym dostępem do informacji

Oprogramowanie zabezpieczające informacje

Klasyfikacja według poziomu kontroli braku niezadeklarowanych zdolności

Zatwierdzony decyzją Przewodniczącego Państwowej Komisji Technicznej przy Prezydencie Federacji Rosyjskiej z dnia 4 czerwca 1999 r. nr 114

1.POSTANOWIENIA OGÓLNE

2.TERMINY I DEFINICJE

Niniejsze wytyczne (RD) ustanawiają klasyfikację oprogramowania (zarówno krajowego, jak i importowanego) narzędzi bezpieczeństwa informacji (IS), w tym wbudowanych w ogólne oprogramowanie systemowe i aplikacyjne, zgodnie z poziomem kontroli nad brakiem w nim niezadeklarowanych możliwości.

Dokument nie dotyczy oprogramowania narzędzi do ochrony informacji kryptograficznej.

Poziom kontroli wyznaczany jest poprzez spełnienie zbioru wymagań określonych w niniejszym RD, nałożonych przez:

Do składu i zawartości dokumentacji przedłożonej przez wnioskodawcę w celu przetestowania oprogramowania do ochrony informacji;

Wytyczne opracowano w celu uzupełnienia:

RD „Zaplecze komputerowe. Ochrona przed nieuprawnionym dostępem do informacji. Wskaźniki zabezpieczenia przed nieuprawnionym dostępem do informacji”, M., Wydawnictwo Wojskowe, 1992;

RD „Systemy zautomatyzowane. Ochrona przed nieuprawnionym dostępem do informacji. Klasyfikacja systemów zautomatyzowanych i wymagania ochrony informacji”, M., Wydawnictwo Wojskowe, 1992;

RD „Zaplecze komputerowe. Zapory ogniowe. Ochrona przed nieuprawnionym dostępem do informacji. Wskaźniki zabezpieczenia przed nieuprawnionym dostępem do informacji”, M., 1997.

Dokument przeznaczony jest dla specjalistów laboratoriów badawczych, klientów i twórców oprogramowania zabezpieczającego informacje podczas monitorowania go pod kątem braku niezadeklarowanych możliwości.

1. POSTANOWIENIA OGÓLNE

1.1. Klasyfikacja dotyczy oprogramowania zaprojektowanego w celu ochrony informacji zastrzeżonych.

1.2. Ustanawia się cztery poziomy kontroli braku niezadeklarowanych zdolności. Każdy poziom charakteryzuje się pewnym minimalnym zestawem wymagań.

1.3. W przypadku oprogramowania służącego do ochrony informacji objętych tajemnicą państwową należy zapewnić poziom kontroli co najmniej trzeci.

1.4. Najwyższy poziom kontroli to pierwszy, wystarczający dla oprogramowania służącego do ochrony informacji sklasyfikowanych jako „OV”.

Drugi poziom kontroli jest wystarczający w przypadku oprogramowania służącego do ochrony informacji oznaczonych „CC”.

Trzeci poziom kontroli jest wystarczający w przypadku oprogramowania służącego do ochrony informacji sklasyfikowanych jako „C”.

1.5 Najniższy poziom kontroli to czwarty, wystarczający dla oprogramowania służącego do ochrony informacji poufnych .

2. TERMINY I DEFINICJE

2.1. Niezadeklarowane możliwości to funkcjonalności oprogramowania, które nie są opisane lub nie odpowiadają opisanym w dokumentacji, których wykorzystanie może naruszyć poufność, dostępność lub integralność przetwarzanych informacji.

Realizacja niezadeklarowanymi funkcjami są w szczególności zakładki programowe.

2.2. Zakładki oprogramowania to celowo dodane do oprogramowania obiekty funkcjonalne, które pod pewnymi warunkami (dane wejściowe) inicjują wykonanie funkcji oprogramowania nieopisanych w dokumentacji, prowadząc do naruszenia poufności, dostępności lub integralności przetwarzanych informacji.

2.3. Obiekt funkcjonalny to element programu realizujący działania mające na celu implementację kompletnego fragmentu algorytmu programu.

Obiektami funkcjonalnymi mogą być procedury, funkcje, gałęzie, operatory itp.

2.4. Obiekt informacyjny to element programu zawierający fragmenty informacji krążących w programie. W zależności od języka programowania zmienne, tablice, rekordy, tabele, pliki, fragmenty pamięci RAM itp. mogą służyć jako obiekty informacyjne.

2.5. Droga wykonania obiektów funkcjonalnych to określona przez algorytm sekwencja wykonanych obiektów funkcjonalnych.

2.6. Rzeczywista droga wykonania obiektów funkcjonalnych to sekwencja obiektów funkcjonalnych, które są faktycznie wykonywane w określonych warunkach (dane wejściowe).

2.7. Trasa krytyczna dla realizacji obiektów funkcjonalnych to trasa, podczas której istnieje możliwość niekontrolowanego naruszenia ustalonych zasad przetwarzania obiektów informacyjnych.

2.8. Analiza statyczna kodów źródłowych programów to zestaw metod monitorowania (nie)zgodności funkcjonalności oprogramowania zaimplementowanych i zadeklarowanych w dokumentacji, w oparciu o analizę strukturalną i dekompozycję kodów źródłowych programu.

2.9. Analiza dynamiczna kodów źródłowych programów to zestaw metod monitorowania (nie)zgodności funkcjonalności oprogramowania zaimplementowanych i zadeklarowanych w dokumentacji, w oparciu o identyfikację rzeczywistych tras wykonania obiektów funkcjonalnych z późniejszym porównaniem z trasami zbudowanymi w procesie analizy statycznej .

3. WYMOGI DOTYCZĄCE POZIOMU ​​KONTROLI

3.1. LISTA WYMAGAŃ

Tabela 1.

Oznaczenia

„-” – dla tego poziomu nie ma wymagań;

„+” – nowe lub dodatkowe wymagania;

"=" - wymagania są takie same jak wymagania poprzedniego poziomu.

3.2. WYMAGANIA DLA CZWARTEGO POZIOMU ​​KONTROLI

3.2.1. Kontrola składu i zawartości dokumentacji

Dokumentacja składana przez wnioskodawcę musi zawierać:

Specyfikacja (GOST 19.202-78), zawierająca informacje o składzie oprogramowania i dokumentacji do niego;

Opis programu (GOST 19.402-78), zawierający podstawowe informacje o składzie (ze wskazaniem sum kontrolnych plików wchodzących w skład oprogramowania), strukturze logicznej i środowisku działania oprogramowania, a także opis metod, technik i zasad do obsługi urządzeń technologicznych przy tworzeniu oprogramowania;

Opis aplikacji (GOST 19.502-78), zawierający informacje o przeznaczeniu oprogramowania, zakresie zastosowania, zastosowanych metodach, klasie zadań do rozwiązania, ograniczeniach aplikacji, minimalnej konfiguracji sprzętu, środowisku operacyjnym i procedurze operacyjnej.

Teksty źródłowe programów (GOST 19.401-78) zawartych w oprogramowaniu.

W przypadku importowanego oprogramowania skład dokumentacji może różnić się od wymaganej, ale treść musi spełniać wymagania określonych GOST.

3.2.2. Monitorowanie stanu początkowego oprogramowania

Kontrola polega na rejestracji stanu początkowego oprogramowania i porównaniu uzyskanych wyników z podanymi w dokumentacji.

Wynikiem monitorowania stanu początkowego oprogramowania powinny być obliczone unikalne wartości sum kontrolnych modułów obciążeniowych i kodów źródłowych programów zawartych w oprogramowaniu.

Dla każdego pliku zawartego w oprogramowaniu należy obliczyć sumy kontrolne.

3.2.3. Analiza statyczna kodów źródłowych programów

Analiza statyczna kodów źródłowych programu powinna obejmować następujące operacje technologiczne:

Kontrola kompletności i braku redundancji tekstów źródłowych oprogramowania na poziomie pliku;

Monitorowanie zgodności tekstów źródłowych oprogramowania z jego kodem obiektowym (bootowym).

3.2.4. Raportowanie

Po zakończeniu badań sporządzany jest protokół (protokół) zawierający wyniki:

Monitorowanie stanu początkowego oprogramowania;

Kontrolowanie kompletności i braku redundancji tekstów źródłowych kontrolowanego oprogramowania na poziomie plików;

Monitorowanie zgodności tekstów źródłowych oprogramowania z jego kodem obiektowym (rozruchowym).

3.3 WYMOGI DLA TRZECIEGO POZIOMU ​​KONTROLI

3.3.1. Kontrola składu i zawartości dokumentacji

Wymagania w pełni obejmują podobne wymagania dla czwartego poziomu kontroli.

Dodatkowo należy przedstawić „Notę wyjaśniającą” (GOST 19.404-79), zawierającą podstawowe informacje o przeznaczeniu komponentów zawartych w oprogramowaniu, parametrach przetwarzanych zbiorów danych (podschematy baz danych), wygenerowanych kodach powrotu, opis stosowanych zmiennych, działających algorytmów itp.

3.3.2. Monitorowanie stanu początkowego oprogramowania

Wymagania w pełni obejmują podobne wymagania dla czwartego poziomu kontroli.

3.3.3.Analiza statyczna kodów źródłowych programów

Oprócz podobnych wymagań dla czwartego poziomu kontroli dodatkowo nałożone są następujące wymagania:

Kontrola kompletności i braku redundancji kodów źródłowych oprogramowania na poziomie obiektów funkcjonalnych (procedur);

Kontrola połączeń obiektów funkcjonalnych (moduły, procedury, funkcje) w celu zarządzania;

Monitorowanie połączeń obiektów funkcjonalnych (modułów, procedur, funkcji) w oparciu o informacje;

Sterowanie obiektami informacyjnymi różnego typu (na przykład zmiennymi lokalnymi, zmiennymi globalnymi, zmiennymi zewnętrznymi itp.);

Utworzenie listy tras wykonania obiektów funkcjonalnych (procedury, funkcje).

3.3.4. Dynamiczna analiza kodów źródłowych programów

Analiza dynamiczna kodów źródłowych programu powinna obejmować następujące operacje technologiczne:

Monitorowanie wykonania obiektów funkcjonalnych (procedury, funkcje);

Porównanie rzeczywistych tras wykonania obiektów funkcjonalnych (procedur, funkcji) z trasami zbudowanymi w procesie analizy statycznej.

3.3.5. Raportowanie

Oprócz podobnych wymagań dla czwartego poziomu kontroli, raport (protokół) musi dodatkowo zawierać wyniki:

Monitorowanie kompletności i braku redundancji tekstów źródłowych kontrolowanego oprogramowania na poziomie obiektów funkcjonalnych (procedur);

Sterowanie połączeniami obiektów funkcjonalnych (moduły, procedury, funkcje) w celu zarządzania;

Sterowanie połączeniami obiektów funkcjonalnych (modułów, procedur, funkcji) w oparciu o informacje;

Sterowanie obiektami informacyjnymi różnego typu (na przykład zmiennymi lokalnymi, zmiennymi globalnymi, zmiennymi zewnętrznymi itp.);

Utworzenie listy tras realizacji obiektów funkcjonalnych (procedury, funkcje);

Monitorowanie wykonania obiektów funkcjonalnych (procedury, funkcje);

Porównanie rzeczywistych tras wykonania obiektów funkcjonalnych (procedur, funkcji) z trasami zbudowanymi w procesie analizy statycznej.

3.4. WYMAGANIA DLA DRUGIEGO POZIOMU ​​KONTROLI

3.4.1. Kontrola składu i zawartości dokumentacji

3.4.2. Monitorowanie stanu początkowego oprogramowania

Wymagania w pełni obejmują podobne wymagania dla trzeciego poziomu kontroli.

3.4.3. Analiza statyczna kodów źródłowych programów

Kontrola kompletności i braku redundancji tekstów źródłowych kontrolowanego oprogramowania na poziomie obiektów funkcjonalnych (funkcji);

Syntaktyczna kontrola obecności określonych struktur w kodach źródłowych oprogramowania z listy (bazy) potencjalnie niebezpiecznych konstrukcji oprogramowania;

Utworzenie listy tras realizacji obiektów funkcjonalnych (oddziałów);

Analiza tras krytycznych realizacji obiektów funkcjonalnych (procedur, funkcji) dla określonych przez eksperta list obiektów informacyjnych;

Budowa schematów blokowych, diagramów itp. z tekstów źródłowych sterowanego oprogramowania, a następnie analiza porównawcza algorytmu działania obiektów funkcjonalnych (procedury, funkcje) z algorytmem działania podanym w „Nocie objaśniającej”.

3.4.4. Dynamiczna analiza kodów źródłowych programów

Oprócz podobnych wymagań dla trzeciego poziomu kontroli dodatkowo nałożone są następujące wymagania:

Monitorowanie realizacji obiektów funkcjonalnych (oddziałów);

Porównanie rzeczywistych tras realizacji obiektów funkcjonalnych (odgałęzień) z trasami zbudowanymi w procesie analizy statycznej

3.4.5 Raportowanie

Oprócz podobnych wymagań dla trzeciego stopnia kontroli, raport (protokół) musi dodatkowo zawierać wyniki:

Monitorowanie kompletności i braku redundancji tekstów źródłowych kontrolowanego oprogramowania na poziomie obiektów funkcjonalnych (funkcji);

Syntaktyczna kontrola obecności określonych konstrukcji w kodach źródłowych oprogramowania z listy (bazy danych) konstrukcji potencjalnie niebezpiecznych;

Generowanie listy tras realizacji obiektów funkcjonalnych (oddziałów);

Analiza tras krytycznych realizacji obiektów funkcjonalnych (procedur, funkcji) dla określonych przez eksperta list obiektów informacyjnych;

Budowa schematów blokowych, diagramów itp. z tekstów źródłowych sterowanego oprogramowania, a następnie analiza porównawcza algorytmu działania obiektów funkcjonalnych (procedury, funkcje) z algorytmem działania podanym w „Nocie objaśniającej”;

Sterowanie realizacją obiektów funkcjonalnych (oddziałów);

Porównanie rzeczywistych tras realizacji obiektów funkcjonalnych (odgałęzień) z trasami zbudowanymi w procesie analizy statycznej.

3.5. WYMOGI DLA PIERWSZEGO POZIOMU ​​KONTROLI

3.5.1. Kontrola składu i zawartości dokumentacji

3.5.2. Monitorowanie stanu początkowego oprogramowania

Wymagania w pełni obejmują podobne wymagania dla drugiego poziomu kontroli.

3.5.3. Analiza statyczna kodów źródłowych programów

Oprócz podobnych wymagań dla drugiego poziomu kontroli dodatkowo nałożone są następujące wymagania:

Monitorowanie zgodności tekstów źródłowych oprogramowania z jego kodem obiektowym (rozruchowym) za pomocą certyfikowanych kompilatorów;

Semantyczna kontrola obecności określonych struktur w kodach źródłowych oprogramowania

3.5.4. Dynamiczna analiza kodów źródłowych programów

Wymagania w pełni obejmują podobne wymagania dla drugiego poziomu kontroli.

3.5.5. Raportowanie

Oprócz podobnych wymagań dla drugiego stopnia kontroli, raport (protokół) musi dodatkowo zawierać wyniki:

Monitorowanie zgodności tekstów źródłowych oprogramowania z jego kodem obiektowym (rozruchowym) za pomocą certyfikowanych kompilatorów;

Semantyczna kontrola obecności określonych struktur w kodach źródłowych oprogramowania z listy (bazy danych) obiektów potencjalnie niebezpiecznych.