TRUSTED WORKSTATION FOR PROCESSING OF
MULTILEVEL CLASSIFIED INFORMATION
BEZPIECZNA STACJA ROBOCZA DO
PRZETWARZANIA DANYCH O RÓŻNYCH
KLAUZULACH NIEJAWNOŚCI
Zbigniew Zieliński
1, Marek Brudka
2, Janusz Furtak
1,
Andrzej Stasiak
1, Jan Chudzikiewicz
1, Adam Kozakiewicz
3,
Anna Felkner
3, Marek Małowidzki
41
Wojskowa Akademia Techniczna
jfurtak@wat.edu.pl ; zzielinski@wat.edu.pl; astasiak@wat.edu.pl; jchudzikiewicz@wat.edu.pl 2 Filbico Sp. z o.o., Prymasa S. Wyszyńskiego 7, mbrudka@filbico.pl
3
NASK – adam.kozakiewicz@nask.pl , anna.felkner@nask.pl 4
Wojskowy Instytut Łączności, Zegrze, m.malowidzki@wil.waw.pl
Abstract: The project of trusted workstation for special applications (TWSA) is directed toward the combination of the existing hardware and software virtualization with cryptography and identification technologies to ensure the security of multilevel classified data by means of some formal methods. It is anticipated, that the final solution will provide a ready-to-deploy base platform for various workstations, especially in C2 systems. In the paper, a novel method for secure software design is introduced. The method employes dedicated tools to verify the confidentiality and the integrity of data using UML models. In general, the UML security models are embedded in and simulated with the system architecture models, thus the security problems in TWSA can be detected early during the software design. The application of UML topology models enables also to verify the fundamental requirement for MLS systems, namely the hardware isolation of subjects from different security domains. Additionally, the configuration of TWSA is defined within the topology model and validated against the constraints of hardware resources.
Keywords: data processing, cryptography, secure software
Streszczenie: Projekt bezpiecznej stacji do zastosowań specjalnych (BSdZS) ukierunkowany jest na integrację technik sprzętowej i programowej wirtualizacji z kryptografią i zaawansowaną identyfikacją, wykorzystując metody formalne do zapewnienia poufności i integralności danych o różnych klauzulach niejawności. W referacie zaproponowano autorskie podejście do projektowania bezpiecznego oprogramowania, z wykorzystaniem dedykowanych narzędzi do weryfikacji poufności i integralności przetwarzanych danych na podstawie modeli UML. W zaproponowanej metodzie projektowania integracja modeli zabezpieczeń z modelami systemów opisanych w języku UML, umożliwia ich symulację, co
pozwala na weryfikację problemów bezpieczeństwa projektowanego
oprogramowania BSdZS już na etapie modelowania. Zastosowanie modelu topologii daje możliwość badania sprzętowej separacji procesów przetwarzania danych, należących do różnych domen bezpieczeństwa, co jest jednym z elementów weryfikacji systemów typu MLS. Dodatkowo model topologii umożliwia definiowanie konfiguracji BSdZS, a następnie walidację reguł dotyczących skończoności zasobów fizycznych stacji.
1 Wprowadzenie
Problematyka budowy wiarygodnych specjalizowanych systemów komputerowych SCS (ang. Specialized Computer Systems), przetwarzających dane o różnych poziomach wrażliwości (ang. sensitivity) staje się szczególnie aktualna, zwłaszcza w odniesieniu do zastosowań SCS w instytucjach rządowych, militarnych czy finansowych. Problem przetwarzania informacji o różnych poziomach wrażliwości był intensywnie badany już od początku lat 70-tych XX wieku [1, 2], 3]. Podstawy formalne tzw. ochrony wielopoziomowej MLS (ang. MultiLevel Security) zostały przedstawione w pracach Bella-LaPaduli (B-LP) [2]. W systemie komputerowym z ochroną wielopoziomową MLS niezbędne jest określenie tzw. dopuszczenia użytkowników do pracy z informacją niejawną, zgodnie z wymogami realizowanych zadań służbowych (zasada „wiedzy koniecznej”) oraz dokonania klasyfikacji informacji, ze względu na wymagany poziom ochrony.
Do zapewnienia poufności i integralności informacji często wykorzystywane są modele B-LP, Biby [4], Clarka-Wilsona [6] zapewniające obowiązkową kontrolę dostępu (ang. Mandatory Access Control – MAC) podmiotów (ang. subject) do zasobów (ang. object ). W kontroli MAC każdemu podmiotowi (może nim być proces) i zasobowi systemu (plik danych, kanał komunikacji itp.) przypisuje się kontekst zabezpieczeń. W celu określenia uprawnień w systemach realizujących MAC konstruowane są etykiety zawierające kontekst zabezpieczeń, a w szczególności pary: <poziom wrażliwości,kategoria informacji>. Na zbiorze etykiet ochrony danych określona jest relacja częściowego porządku, a wobec podmiotów i zasobów muszą być narzucone niezmienne reguły [3, 4, 5], między innymi, reguła zabraniająca „pisania w dół”, reguła zabraniająca „czytania w górę”. Należy podkreślić, że zaimplementowanie w systemach i sieciach komputerowych wymienionych reguł (czyli zbudowanie wiarygodnego systemu opartego wyłącznie na systemie operacyjnym z wielopoziomową ochroną informacji) jest trudne i kosztowne. Wynika to głównie z trudności zbudowania niezawodnego monitora referencyjnego oraz trudności zagwarantowania, że w systemie nie będzie „wycieku” informacji wrażliwej ze względu na możliwość istnienia w systemie operacyjnym tzw. zamaskowanych kanałów komunikacji (ang. covert channels ) [7].
Inne podejście do budowy scentralizowanego (nie rozproszonego) systemu komputerowego typu wielopoziomowego polega na opracowaniu oprogramowania w technologii wirtualizacji [8, 9, 10] do separacji niezależnych domen bezpieczeństwa (ang. Multiple Independent Levels of Security ). Oprogramowanie takie powinno umożliwiać jednoczesne uruchamianie kilku instancji specjalnych systemów operacyjnych na jednym stanowisku komputerowym (stacja robocza, serwer) przeznaczonym do przetwarzania danych o różnych klauzulach wrażliwości (np. jawne, zastrzeżone), bądź do przetwarzania danych w różnych systemach, dla których zachodzi potrzeba separacji danych.
Podejście to stało się dziś w pełni możliwe dzięki dostępnym we współczesnych procesorach Intel i AMD rozwiązaniom sprzętowego wsparcia wirtualizacji z jednej strony i opracowanym pakietom programowym wirtualizacji typu COTS.
Obecnie szeroko stosowane są takie rozszerzenia architektury x86, których celem jest sprzętowe wspomaganie wirtualizacji [8, 9, 10] jak: Intel Virtualization Technology w szczególności VTx, VTd – dla procesorów x86 oraz VTi – dla procesorów IA-64 (Itanium) oraz AMD Virtualization (AMD-V) dla 64-bitowych procesorów x86 AMD. Technologie te pozwalają również (obok sprzętowego wsparcia emulacji maszyny wirtualnej) na zbudowanie zaufanego środowiska, w którym oddzielne maszyny wirtualne (stanowiące odrębne domeny bezpieczeństwa) wykonywane są w odseparowanych partycjach sprzętowych. Realizacja tego typu projektu systemu MLS wymaga integracji dostępnych technologii wirtualizacji (programowych i sprzętowych), zastosowanie metod formalnych służących zarówno zapewnianiu, jak i kontroli poufności i integralności przetwarzania danych oraz technik uwierzytelniania użytkowników. Naturalnym sposobem budowy tego typu systemów staje się podejście komponentowe, w którym zakłada się wykorzystanie gotowych (dostępnych) komponentów sprzętowych, jak i programowych, w szczególności dostępnych pakietów wirtualizacji typu Open Source jak Xen [11] czy KVM [12].
W artykule przedstawiono wymagania na bezpieczną stację roboczą do zastosowań specjalnych (BSdZS), jej architekturę oraz nowatorskie podejście do projektowania bezpiecznego oprogramowania. Nowatorskość podejścia wynika z założenia, że głównym jej celem jest dostarczenie narzędzi do weryfikacji poufności i integralności przetwarzanych danych na podstawie modeli, jak również badania odporności budowanego całego systemu na różnego typu ataki już na etapie jego wytwarzania. Opracowana metoda wytwarzania systemów typu MLS, którą określana będzie jako metoda MDmls (ang Model Driven Multilevel Security ), porządkuje proces wytwarzania SCS typu MLS i wywodzi się z koncepcji MDA (ang. Model Driven
Architecture ) [13, 14], oraz MDD (ang. Model Driven Development ) [15, 16].
Podobne podejście do budowy bezpiecznego oprogramowania przedstawiono w pracy [15], jednak nie obejmuje ono problematyki ochrony wielopoziomowej. W proponowanej metodzie zakłada się, że modelowanie stanowi centrum wszystkich działań wytwórczych, tzn. budowane modele będą wprost ukierunkowane na wytworzenie produktu. Integracja modeli zabezpieczeń z modelami systemów opisanych w języku UML umożliwia ich symulację, co pozwala na weryfikację skuteczności zabezpieczeń projektowanego oprogramowania SCS typu MLS już na etapie modelowania .
2 Sformułowanie wymagań na BSdZS
Rozwiązania techniczne powinny być projektowane i produkowane dla ściśle zdefiniowanych obszarów ich zastosowań. Paradygmat ten jest szczególnie istotny w odniesieniu do urządzeń zapewniających bezpieczeństwo teleinformatyczne. Zbyt szerokie ujęcie zakresu aplikacji BSdZS mogłoby doprowadzić do istotnego wzrostu złożoności zabezpieczeń, kosztów i terminów ich realizacji, a w konsekwencji zmniejszyć szanse osiągnięcia odpowiedniej jakości, odporności i poziomu zaufania do produktu.
Jednym z pierwszych zadań projektu było zatem rozważenie i wybór scenariuszy użycia BSdZS w kontekście uwarunkowań prawnych ograniczających rozwiązania technologiczne.
2.1 Scenariusze użycia BsdZS.
Na potrzeby systematycznej analizy scenariuszy użycia BSdZS przyjęto ad hoc, że najważniejszymi aspektami dyskryminującymi analitycznie przypadki zastosowań są: Zróżnicowanie wymaganych poziomów ochrony informacji przetwarzanych przez poszczególne maszyny wirtualne na: jednoklauzulowe, wieloklauzulowe
i wieloklauzulowe międzynarodowe, przy czym w dalszej analizie nie uwzględniano zastosowań wieloklauzulowych międzynarodowych.
Liczba użytkowników posiadających dostęp do BSdDZ zgodna z kategoryzacją: zastosowania samodzielne , w których do systemu posiada dostęp wyłącznie Administrator AST i Inspektor Bezpieczeństwa IBT, oraz wielodostępne, w których do systemu posiadają dostęp użytkownicy o innych uprawnienia niż AST i IBT.
Dołączalność BSdZS do innych sieci teleinformatycznych pogrupowana na zastosowania autonomiczne, bez dostępu do sieci TI, lokalne z z dostępem do jednej sieci lokalnej i rozległe, z dostępem do wielu sieci TI zlokalizowanych w różnych strefach ochrony.
Analizując uwarunkowania prawne dla wszystkich kombinacji wymienionych aspektów wskazano praktycznie ważne przypadki zastosowań BsdZS i uporządkowane je pod względem narastającej trudności wdrożenia:
Jednoklauzulowe, wielodostępne i rozległe, w których stacja robocza dołączona jest do
kilku sieci o takim samym poziomie ochrony, ale różnych kategoriach przetwarzanych informacji np. sieci działu projektantów i sieci działu finansowego.
Wieloklauzulowe, wielodostępne i autonomiczne, których przykładem może być
autonomiczne, kancelaryjne stanowisko do przetwarzania informacji niejawnych typu BSK.
Wieloklauzulowe, samodzielne i rozległe, w których BsdZS może być platformą
bazową do konstrukcji zabezpieczeń teleinformatycznych do przesyłania danych pomiędzy sieciami o różnych klauzulach.
Wieloklauzulowe, wielodostępne i rozległe obejmujące wszystkie pozostałe
zastosowania, jednak charakteryzujące się największym złożonością formalno-prawną oraz największym ryzykiem utraty poufności informacji.
2.2 Wpływ uwarunkowań prawnych na rozwiązania BsdZS
Wykonany przegląd krajowych regulacji prawnych z zakresu bezpieczeństwa teleinformatycznego prowadzi do spostrzeżenia, że regulacje te odnoszą się głównie do teleinformatyki poziomu „fizycznego”, i nie zawierają specyficznych wymagań odnoszących się do wirtualizacji. Brak stosownych przepisów nie oznacza jednak, że zgodnie z zasadą: „co nie jest dozwolone – jest zakazane”, wykorzystanie wirtualizacji jako mechanizmu zapewniającego bezpieczeństwo teleinformatyczne będzie możliwe dopiero po zmianie stanu prawnego.
W ramach wpływu uwarunkowań prawnych na rozwiązania BSdZS na podstawie ustawy o ochronie informacji niejawnych UOIN [28], rozporządzeń wykonawczych i wytycznych z zakresu bezpieczeństwa teleinformatycznego podjęto próbę identyfikacji wymagań specyficznych dla wirtualizacji stacji roboczych.
Za najważniejsze z wymagań należy uznać konieczność zapewnienia przez BSdZS ochrony odpowiadającej najwyższej z klauzul przypisanych do poszczególnych specjalnych systemów operacyjnych SSO. Przyjęto, że ze względu na przewidywane klauzule informacji niejawnych, BSdZS powinna zostać oceniona na poziomie uzasadnionego zaufania nie niższym niż EAL 4. Ustalono, że dla wybranych potencjalnych zastosowań adekwatnym trybem bezpieczeństwa pracy stacji powinien być tryb przedziałowy, czyli od BSdZS należy oczekiwać m.in. technicznego wsparcia obowiązkowej kontroli dostępu MAC.
W zastosowaniach rozległych, w których poszczególne SSO dołączone będą do lokalnych sieci teleinformatycznych współpracujących ze sobą podmiotów, BSdZS spełniać będzie przesłanki definicji połączenia międzysystemowego. Bezpośrednią tego konsekwencją dla zastosowań wieloklauzulowych będzie konieczność wdrożenia zabezpieczeń teleinformatycznych uniemożliwiających utratę poufności przetwarzanych informacji. Zabezpieczenia te powinny zostać opatrzone dowodem kontrolowanej separowalności SSO, w tym analizą ukrytych kanałów przekazywania informacji.
Zastosowania rozległe prowadzą do specyficznych wymagań z zakresu oznakowywania i ewidencji stacji roboczej oraz poszczególnych SSO, wymagań w pewnym stopniu analogicznych do wprowadzenia terminala zdalnego systemu TI w strefie ochrony niekontrolowanej przez właściciela (gestora) tego systemu. W pierwszej kolejności komputer BSdZS wraz z systemem macierzystym powinien być oznakowywany i ewidencjonowany w ramach systemu TI miejsca dyslokacji. Maszyny wirtualne SSO dołączanych zdalnie do innych systemów TI powinny być raczej oznakowywane i ewidencjonowane w ramach zdalnych systemów TI. BSdZS powinno zatem wspierać na poziomie technicznym i proceduralnym czynności związane z ewidencją i oznakowywaniem maszyn wirtualnych oraz ich kopii bezpieczeństwa.
Wynikającą z UOIN ewentualną konieczność stosowania środków ochrony elektromagnetycznej BSdZS należy przede wszystkim odnosić do poziomu „fizycznego” stacji roboczej. Poddane analizie regulacje prawne nakazują wprawdzie separację elektromagnetyczną linii sygnałowych i zasilających części jawnej (BLACK) od części niejawnej (RED) systemów TI, jednak z obowiązku tego nie wynika konieczność separacji części przetwarzających informacje niejawne o różnych klauzulach. Przyjęto zatem, że wszystkie maszyny wirtualne osadzone na BSdZS powinny zostać jednocześnie oznaczone jako RED albo BLACK.
2.3 Specyfikacja wymagań funkcjonalnych
W otoczeniu BSdZS można wyróżnić trzy rodzaje aktorów: administratora systemu, inspektora bezpieczeństwa teleinformatycznego (zwanym dalej inspektorem), użytkownika SSO (zwany dalej użytkownikiem) (rys. 1).
Inspektor wraz z administratorem i innymi osobami opracowują szczególne wymagania bezpieczeństwa systemu (SWBS) i procedury bezpiecznej eksploatacji (PBE). W ramach SWBS określony zastaje poziom bezpieczeństwa (PB) instalowanych w BSdZS maszyn wirtualnych oraz uprawnienia podmiotów (użytkowników). PB obejmuje klauzulę informacji dopuszczonej do przetwarzania oraz jej zbiór kategorii (zakres). Każdy poziom jest opisany (zgodnie z modelem Bella-LaPaduli) przez parę: parę: < k, c > gdzie k ∈ K oznacza klauzulę tajności informacji (K = { jawne ,zastrzeżone ,poufne ,tajne }), a c ∈ C jest podzbiorem zbioru kategorii informacji c = { c1, c2, …, cL }, przykładowo C = { Do, Sn, So,Dc ,… }, gdzie symbole Do, Sn, So, Dc oznaczają odpowiednio dane osobowe, środki naprowadzania, sytuację operacyjną, dane o celach.
Klauzule są uporządkowane (od mniej ważnych, do ważniejszych) ∀i=(1, …,4) ki ≤ ki+1, a kategorie nie. Poziomy bezpieczeństwa możemy porównywać, przykładowo dla Pba = < ka, C a> i Pbb = < kb, Cb >, jeśli spełnione są następujące warunki: kb ≤ ka, i Cb ⊆ Ca wtedy Pbb ≤ PBa (poziom PBa będzie wyższy lub równy niż poziom PBb). Niech Pbb = < poufne, { Do, Dc } >, a Pba = < tajne, { Do, So, Dc } >, wtedy mamy PBb ≤ PBa, bo spełnione są następujące zależności: poufne < tajne i { Do, Dc } ⊆ { Do, So, Dc }. Należy również pamiętać, że nie wszystkie pary poziomów bezpieczeństwa są porównywalne. Prowadzi to do wykorzystania pojęcia kraty poziomów bezpieczeństwa.
Bezpieczeństwo systemu według modelu Bella-LaPaduli jest spełnione, jeśli zachowane są następujące aksjomaty: bezpieczeństwa prostego, gwiazdki, stałości,
bezpieczeństwa uznaniowego, niedostępności obiektu nieaktywnego, niezależności stanu początkowego.
Aksjomaty te zostały przyjęte we wszystkich modelach stosujących obowiązkową kontrolę dostępu do informacji. Spełnienie ich zapewnia, że informacje klasyfikowane w systemie nie będą dostępne dla podmiotów, które nie uzyskały odpowiedniej autoryzacji. Inspektor określa atrybuty bezpieczeństwa istniejących w BSdZS specjalnych systemów operacyjnych SSOk (k = 1, 2, …, n ), takie jak ich klauzule oraz klasy zastosowań, zarządza bazą danych użytkowników i ich poświadczeń bezpieczeństwa, określa możliwości uzyskania dostępu do zasobów dla każdej z domen. Prawa dostępu dla domen są określane poprzez etykiety bezpieczeństwa. MMW udostępnia inspektorowi zarządzanie etykietami bezpieczeństwa i kontrolę ich alokacji w systemie.
Administrator wykonuje kopie bezpieczeństwa maszyny macierzystej i maszyn wirtualnych, tworzy nowe konta dla użytkowników SSO (na zlecenia pełnomocnika), tworzy i modyfikuje konfiguracje maszyn wirtualnych (rys. 2). Użytkownik, w modelu wymagań na monitor MMW, z (rys. 1) ogranicza swoje zadania do uruchomienia SSO.
Rys. 2. Podsystem administrowania BSdZS
3 Architektura BSdZS
Zasadnicze znaczenie przy tworzeniu złożonych systemów komputerowych odgrywa architektura rozwiązania. W odniesieniu do BSdZS za szczególnie ważne należy uznać
sprzętowe i programowe elementy architekury z uwagi na ich istotny wpływ na bezpieczeństwo systemu teleinformatycznego
3.1. Architektura sprzętowa
Zakłada się wykorzystanie komponentów, które umożliwiają sprzętowe wsparcie technologii bezpieczeństwa oraz sprzętowe wsparcie wirtualizacji. Do wydzielenia odrębnych partycji z odizolowanymi środowiskami wykonawczymi wykorzystana zostanie technologia Trusted Execution Technology TXT, natomiast istotną rolę w zapewnieniu integralności BSdDZ odegra komponent TMP (Trusted Platform
Module) pozwalający m.in. tworzyć i bezpiecznie przechowywać klucze szyfrujące.
Projekt sprzętowy, ze względu na zastosowane podejście (wykorzystanie gotowych komponentów), ogranicza się do określenia konfiguracji, opisującej cechy zastosowanego rozwiązania. Zaproponowana architektura sprzętowa BSdZS bazuje na maszynie o architekturze Intel Westmere z dwoma procesorami serii Xeon model E5630 (rys. 3), każdy z nich zawiera po 4 rdzenie procesorów. Taka architektura daje możliwości rozdziału odpowiedzialności pomiędzy poszczególne komponenty sprzętowe, umożliwia rozdzielenie przepływów informacji w obrębie sprzętu i pozwala
na separację partycji zawierających odrębne domeny bezpieczeństwa. Schemat blokowy systemu opartego na procesorach Xeon serii 5600 przedstawiono na rys. 4. W tym zakresie projektu architektury proponuje się wykorzystanie języka UML
rozszerzonego o tzw. modele topologiczne, których. budowa wspierana jest przez środowisko CASE - Rational Software Architect (RSA).
3.2. Architektura oprogramowania
W architekturze BSdZS wyróżnić można takie elementy jak bezpieczną platformę systemową (BPS) oraz uruchamialne wersje specjalne systemów operacyjnych SSO. Ogólny schemat architektury BSdZS przedstawiono na rys. 3.
Zasadniczymi elementami architektury BSdZS stanowiącą zatem maszyny wirtualne VMi oraz BSP, co zapisywać będziemy w postaci formuły: BsdZS := BSP + {VMi}, gdzie i = { 1, …, n }. BSP tworzą jądro systemu operacyjnego Linux, jego rozszerzenie w postaci komponentu (SELinux) i monitor maszyn wirtualnych (MMW), BSP := MMV Linux_Kernel + SELinux. BSP umożliwia uruchamianie i nadzorowanie działania specjalizowanych systemów operacyjnych SSOi
( i = 1, 2, …, n ) oraz działających w ich środowisku programów użytkowych {PU}, tworzących maszynę wirtualną Vmi := SSOi + {PU}i.
Kluczowym komponentem BSdZS jest monitor MMW odpowiadający za uruchamianie maszyn wirtualnych zgodnie ze zdefiniowanymi zasadami bezpieczeństwa (z wykorzystaniem sprzętowego wspomagania) oraz ich przełączanie z zapewnienia separacji zasobów. Założono, że projektowane oprogramowanie MMW powinno umożliwiać jednoczesne uruchomienie kilku (z wielu możliwych) instancji wersji specjalnych systemów operacyjnych SSOi na jednym stanowisku komputerowym z zapewnieniem kontroli dostępu, ochrony kryptograficznej oraz ścisłej kontroli przepływu danych. Liczba uruchamianych instancji maszyn wirtualnych zależy od konfiguracji stacji, w szczególności od liczby fizycznych procesorów i ich rdzeni. Przykładowo (rys. 4), BSP nadzoruje pracę n maszyn wirtualnych, z których jednocześnie działają dwie VM1 i VM2 i odpowiednio, na VM1 aktywny jest {PU}1 (co przedstawimy jako VM1 → {PU}1 ), VM2 aktywny jest {PU}2 (co przedstawimy jako VM2 → { PU}2 ). MMW zarządza dostępem zarówno do maszyn wirtualnych SSOi, jak i do zasobów sprzętowych (fizycznych i wirtualizowanych). W projekcie założono również, że pracująca w ramach danej maszyny wirtualnej (VM) instancja wersji specjalnej systemu operacyjnego ( SSO ) stanowi odrębną domenę bezpieczeństwa (ang. security domain ) (SD) Vmi [ SSOi ] = DBi, a w każdej z domen dopuszcza się przetwarzanie danych, zakwalifikowanych do różnych poziomów zabezpieczeń (ang. security levels ). Na rys. 4 przedstawiono dwie domeny bezpieczeństwa i z każdą z nich związano jedną maszynę wirtualną.
Warto zauważyć, że zarówno jądro systemu operacyjnego, jak i wersje specjalne systemów operacyjnych w sensie realizowanego projektu stanowią gotowe komponenty, a ich projekt ograniczać się będzie jedynie do specyfikacji ich interfejsów oraz opisów konfiguracji. Interfejsy zostały opisane w języku UML, a konfiguracje na diagramach topologicznych. W tym zakresie używane są narzędzia CASE - Rational Software Architect (RSA).
Rys. 4 Ogólny schemat architektury BSdZS
4 Kryptograficzna ochrona BSdZS
Nawet w najprostszych systemach i aplikacjach istnieje z reguły wiele miejsc, w których potencjalnie możliwy jest atak na zabezpieczenia, a ich liczba ograniczona jest jedynie inwencją napastnika. Wymienić można trzy podstawowe obszary, w których informacje narażone są na przechwycenie:
podczas wprowadzania (np. z klawiatury);
podczas przesyłania (np. poprzez sieć lokalną czy sieć Internet);
podczas zapisywania (np. na stałych oraz wymiennych nośnikach danych). W zakresie zainteresowania opracowywanego rozwiązania ochrony danych BSdZS leży trzeci z przedstawionych obszarów, obejmujący zabezpieczenie danych zapisywanych na stałych oraz wymiennych nośnikach informacji.
Rys. 5. Schemat architektury BSP
W opracowywanym rozwiązaniu zakłada się, między innymi, możliwość wymiany danych pomiędzy wewnętrznym wobec systemu operacyjnego, nośnikiem danych (dysk twardy komputera), a nośnikiem zewnętrznym (np. dyskiem twardym lub pamięcią typu Flash RAM) przyłączonym do systemu poprzez magistralę USB. Nie dopuszcza się natomiast wykorzystania BSdZS jako pośrednika w wymianie danych pomiędzy nośnikami zewnętrznymi (np. pamięciami typu Flash) przyłączonymi do systemu poprzez magistralę USB. Proces zabezpieczenia wymiany danych powinien spełniać następujące wymagania funkcjonalne:
powinien być realizowany w sposób przeźroczysty dla użytkownika;
nie powinien powodować obciążenia systemu operacyjnego zauważalnego dla użytkownika;
nie powinien mieć istotnego wpływu na szybkość odczytu i zapisu danych na nośnikach danych;
powinien umożliwiać wykonywanie wszelkich operacji dopuszczalnych dla nośników danych, takich jak sprawdzanie powierzchni woluminu pod kątem błędów, czy defragmentacja danych na dyskach.
Spełnienie tych wymagań wymusza wykorzystanie do realizacji procesu zabezpieczenia danych, wydzielonego modułu (sterownika) systemu operacyjnego działającego na poziomie jądra systemu. Schemat poglądowy opracowywanego rozwiązania przedstawiono na rysunku 6. Przyjęto założenie, w którym elementy biorące udział w procesie zabezpieczenia przesyłanych danych podzielono na dwie grupy: elementy wewnętrzne oraz elementy zewnętrzne. Podziału tego dokonano, przyjmując za jego kryterium zależność pomiędzy danym elementem a systemem operacyjnym zainstalowanym na komputerze. Wśród elementów wewnętrznych (na rysunku 6 zaznaczone linią przerywaną) wyróżniono zarówno sprzęt, w postaci dysku twardego komputera, jak również moduły programowe: sterownik, bibliotekę dll udostępniającą funkcje z zaimplementowanymi algorytmami szyfrującymi, moduł generacji kluczy sesji oraz bazę danych kluczy publicznych użytkowników.
Do elementów zewnętrznych (na rys. 6 zaznaczone linią kropkową), podłączanych do komputera poprzez magistralę USB, zaliczamy elementy sprzętowe w postaci pamięci
Software
Hardware
Bezpieczna Platforma Systemowa (MMW+hypervisor Xen+ Linux kernel +SELinux) Specjalny system operacyjny 1 (VM1) (Domena 1) Specjalny system operacyjny k (VM1) (Domena n)
Flash oraz karty identyfikującej użytkownika w postaci karty inteligentnej. Proces zapisu (szyfrowania) danych przesyłanych do zewnętrznej pamięci Flash wymaga zidentyfikowania użytkownika będącego odbiorcą tych danych. Proces zapisu danych inicjowany jest przez aktualnie zalogowanego w systemie użytkownika - operatora. Użytkownik ten może być również odbiorcą danych. Przy realizacji operacji odwrotnej, czyli odczytu (deszyfrowania) pliku, odbiorca danych staje się operatorem. Dla każdego z zapisywanych plików tworzona jest sygnatura, która zawiera informacje niezbędne do jego odczytania. Z oczywistych względów nie może ona być przechowywana na tym samym nośniku, co plik.
5 Metoda projektowania oprogramowania stacji
W procesie budowy BPS odrzucono podejście elaboracyjne (ang. elaborationist
approach ) do MDA na rzecz nowego podejścia translacyjnego (ang. translationist approach ), zakładając budowę rozszerzonych specyfikacji opracowanych modeli PIM
o wykorzystanie języka semantyk akcji ALF (obecnie UAL) z możliwością uruchamiania i debugowania tych modeli w środowisku fUML.
Na obecnym etapie prac wykorzystano środowisko IBM RSA ver. 8.0 rozszerzone o produkt Rational Software Architect Simulation Toolkit, ze wsparciem dla UML Action Language (UAL), które dostarcza podzbioru technologii fUML i ALF opisanych w specyfikacjach OMG (rys. 7).
Wykorzystanie translacyjnego podejścia do budowy systemów zgodnie z koncepcją MDA dostarcza zadowalających wyników ze względu na:
ALGORYTM SZYFROWANIA 1 ALGORYTM SZYFROWANIA N
...
Generowanie klucza sesji Karta identyfikująca użytkownika Baza kluczy publicznych Pamięć FlashSygnatura pliku zaszyfrowanego
Pamięć Flash
Plik zaszyfrowany
USB Dysk twardy komputera
Plik w postaci jawnej
USB
STEROWNIK
Elementy wewnątrz
Elementy zewnętrzne
Rys. 6. Schemat poglądowy systemu zabezpieczenia danych zapisywanych na dysku zewnętrznym
dostępność pełnego wsparcia w zakresie tworzenia języków dziedzinowych zgodnie z MDA 1
możliwości symulacji opracowanych modeli jako narzędzia weryfikacji integralności i poufności danych w środowisku BPS. Symulacja takich modeli jest podobna do debugowania kodu źródłowego i tradycyjnie stanowi najbardziej efektywny sposób znajdowania błędów i ich usuwania;
możliwości opisu konfiguracji BSdZS i jej zasobów (zarówno fizycznych, jak i wirtualizowanych) oraz symulacji ich zachowania, poprzez zastosowanie modeli topologicznych [16, 17, 18, 19, 20];
umożliwienie tworzenia sformalizowanych modeli bezpiecznych systemów, tzn. dodanie środków ekspresji rozszerzających UML i OCL w postaci języka semantyk akcji (obecnie UML Action Language (UAL);
umożliwienie wykorzystania podejścia komponentowego do projektowania i budowy architektury BPS, której elementami obok MMW są gotowe komponenty: moduł jądra SE Linux i XEN hypervisor (rys. 5).
Rys. 7 . Model środowiska wytwarzania oprogramowania TSP zgodnie z MDmlS
1
Spełnienie tego wymagania opracowywanej stanowi istotny element opracowywanej metody MDmlS i zdefiniowanego na jej potrzeby języka mlsML.
W proponowanej metodzie kluczowe znaczenie mają działania związane z modelowaniem języków dziedzinowych DSM (ang. Domain-specific modeling [25]. Modelowanie realizowane jest w następujących krokach: szkic języka dziedzinowego DSL (ang. Domain-specific Languages), projekt i implementacja języka dziedzinowego, utworzenie profilu UML dla języka dziedzinowego, utworzenie reprezentacji piktograficznej profilu UML, opracowanie transformacji modeli.
Budowa nowego języka klasy Domain Specific Languages wymaga utworzonego wcześniej metamodelu, ponieważ dopiero na jego podstawie można określić profil. Do zdefiniowania i reprezentacji metamodelu zostanie wykorzystany standard
Meta-Object Facility (MOF), zatwierdzony przez organizację OMG. Budowane profile
UML ( mlsML4MAC, mlsML4RBAC), w ramach proponowanej metody, mają za zadanie, spełniać następujące cele:
integrować DSL z UML - notacja języka UML jest bazą dla tworzonego profilu, a wiedza zwarta w profilu oparta jest na metamodelu dostarczanym również z UML,
ułatwiać ponowne użycie – opracowane języki dziedzinowe będą stanowiły bibliotekę, do której można się zawsze odwołać wskazując jedynie właściwe dziedziny. Dodatkową korzyścią z takiego podejścia będzie standaryzacja języków dziedzinowych oraz powiązane z nimi transformacje jako dostępne zasoby wielokrotnego użycia.
Zbudowany język bazował na koncepcjach MDA i MDD, dlatego jego zasadniczym celem było szybkie osiągnięcie szkieletu kodu implementującego produkt. DSL zbudowany został za pomocą zdefiniowanych wcześniej modeli (wymagań, dziedziny), co pociągało za sobą wymóg budowy abstrakcyjnej składni, identyfikację pojęć, wyszczególniania dobrze ukształtowanych ról, operacji i ograniczeń oraz walidacji i testowania modeli.
W zaproponowanej metodzie projektowania MDmls dzięki integracji modeli zabezpieczeń z modelami SCS typu MLS (opisanych w języku UML) uzyskuje się możliwość symulacji modeli, co pozwala na weryfikację wielu problemów bezpieczeństwa projektowanego systemu już na etapie modelowania. Zastosowanie modelu topologii daje również możliwość badania (fizycznej) separacji procesów przetwarzania danych należących do różnych domen bezpieczeństwa, co jest jednym z elementów weryfikacji systemów typu MLS. Dodatkowo model topologii umożliwia definiowanie konfiguracji BSdZS, a następnie walidację reguł dotyczących wyczerpania zasobów fizycznych stacji (wynikających z jej aktualnej konfiguracji). Zaproponowaną metodę wyróżnia sposób traktowania implementacji systemu, która jest związana nie z jego wytwarzaniem, ale z jego wdrożeniem. Zauważmy, że walidacja modelu nie wymaga implementacji, ponieważ sam model można uruchamiać, animować i testować.
6 Podsumowanie
BSdZS znajduje się aktualnie na etapie walidacji opracowanych modeli i ich implementacji. Projektowane są rozwiązania w zakresie uwierzytelniania oraz ochrony kryptograficznej dysków stałych i wymiennych. Przygotowywane są wersje specjalne systemów Windows i Linux (Red Hat).
W ramach projektu opracowana została metoda projektowania systemu typu MLS. Integracja modeli zabezpieczeń z modelami systemów opisanych w języku UML umożliwia ich symulację, co pozwoliło na weryfikację problemów bezpieczeństwa projektowanego oprogramowania BSdZS już na etapie modelowania.
W najbliższym czasie planowane jest przeprowadzenie testów walidacyjnych bezpieczeństwa stacji roboczej.
Zintegrowanie w projekcie BSdZS dostępnych technologii wirtualizacji (programowych i sprzętowych), zastosowanie metod formalnych służących zarówno zapewnianiu, jak i kontroli poufności i integralności przetwarzania danych, a w szczególności – metod kryptograficznych do zabezpieczania dysków stałych i wymiennych oraz technik uwierzytelniania użytkowników pozwoli (zdaniem autorów) na dostarczenie kompleksowego rozwiązania, które może stanowić podstawę opracowywania i wdrażania platformy systemowej stanowiącej, między innymi, infrastrukturę dla systemów wsparcia dowodzenia.
7 Literatura
[1] Anderson J. P.: Computer Security Technology Planning Study. Vol. II ESD-TR-73-51. Electronic System Division. Air Force System Command. Hansom Field, Bedford. MA, 01730. 1973
[2] Bell D. E., La Padula L. J.: Secure Computer System: Unified Exposition and
Multics Interpretation, ESD-TR-75-306, Bedford, MA: ESD/AFSC, Hanscom
AFB ( http://csrc.nist.gov/publications/history/bell76.pdf ).
[3] Bell D. E.: Looking Back at the Bell-La Padula Model. Reston VA, 20191, 2005 [4] Biba K.J.: Integrity Consideration for Secure Computer System, MTR-3153, 1975 [5] Brudka M. Furtak J., Ponad barierami - łączenie sieci o różnych klauzulach,
Biuletyn IAiR, nr 26, 2009
[6] Clark D., Wilson D.R.: A Comparison of Commercial and Military Computer
Security Policies. Proc. IEEE Symposium on Research in Security and Privacy,
1987, 184-194.
[7] Smith R.: Cost profile of a highly assured, secure operating system, ACM Transactions on Information and System Security, Vol. 4, No. 1, 2001, 72–101 [8] Robin, J.S., Irvine, C.E.: Analysis of the Intel Pentium’s Ability to Support a Secure
Virtual Machine Monitor. In: Proceedings of the 9th USENIX Security
Symposium, Denver, Colorado, USA, 2000
[9] Irvine C. E., Levin T. E., Nguyen T. D. and others, Overview of a High Assurance
Architecture for Distributed Multilevel Security, Proceedings of the 2004 IEEE
Systems, Man and Cybernetics Information Assurance Workshop, West Point, NY, 2004
[10] Methods and Applications of System Virtualization using Intel® Virtualization Technology(Intel® VT), Intel® Technology Journal, Vol. 13, Issue 01, March 2009 [11] Barham P., Dragovic B., Fraser K. and others: Xen and the Art of Virtualization,
University of Cambridge Computer Laboratory, CGF Brussels, 2004
[12] Kivity A., Kamay Y., Laor D. and others, KVM: the Linux Virtual Machine
Monitor, Proceedings of the Linux Symposium, Ottawa, Ontario, 2007, 225–230
[13] Frankel D. S.: Model Driven Architecture: Applying MDA to Enterprise Computing. John Wiley & Sons, 2003
[14] Dąbrowski W., Stasiak A., Wolski M.: „Modelowanie systemów informatycznych
w języku UML 2.1”, PWN, Warszawa, 2007
[15] Lodderstedt T., Basin D. A., Doser J.: SecureUML: A UML-based modeling
language for model-driven security. In: 5th International Conference 2002, LNCS,
vol. 2460, 2002, 426 – 441
[16] Planning deployment with the topology editor, IBM Tutorial, 2008 [17] Modeling deployment topologies, IBM Tutorial, 2008
[18] Narinder M.: Anatomy of a topology model in Rational Software Architect Version 7.5: Part 1: Deployment modeling, IBM, 2008
[19] Narinder Makin: Anatomy of a topology model used in IBM Rational Software Architect Version 7.5: Part 2: Advanced concepts, IBM, 2008
[20] Willard S.: General topology, Courier Dover Publications, 2004
[21] Li N., Mitchell J.C.: RT: A Role-Based Trust Management Framework. In: 3rd DARPA Information Survivability Conference and Exposition (DISCEX III), 2003, 201–212
[22] King S.T., Chen P.M., Wang Y., Verbowski C., Wang H.J., Lorch J.R.: SubVirt:
Implementing Malware with Virtual Machines. In: IEEE Symp. on Security and
Privacy, 2006
[23] Ferrie P.: Attacks on Virtual Machine Emulators. Association of Anti Virus Asia Researchers Conference, Auckland, New Zealand, 2006
[24] Mellor S., Balcer M.: Executable UML: A Foundation for Model-Driven
Architecture, wyd. Addison-Wesley Professional, 2002
[25] Fowler, M. i Parsons, R.:Domain Specific Languages. Addison Wesley, 2010 [26] Fowler, M.: Patterns of Enterprise Application Architecture. Addison Wesley, 2002 [27] Jürjens J.: Secure Systems Development with UML, Springer, 2010
[28] Ustawa o ochronie informacji niejawnych, 5 sierpnia 2010, Dz.U. 2010 nr 182 poz.1228
Zbigniew Zieliński ukończył z wyróżnieniem studia na Wydziale Cybernetyki Wojskowej Akademii Technicznej w 1978 roku. W 1988 obronił pracę doktorską w specjalności systemy informatyczne. Przez cały okres pracy zawodowej związany jest z WAT. Uczestniczył w wielu pracach naukowo-badawczych. Obecnie kieruje pracami badawczymi z zakresu diagnostyki systemowej oraz projektowania systemów specjalizowanych. Jego zainteresowania naukowe koncentrują się wokół problematyki diagnozowania sieci komputerowych oraz bezpieczeństwa teleinformatycznego. Marek Brudka ukończył Wydział Elektroniki i Technik Informacyjnych Politechniki Warszawskiej z roku 1994. W roku 2000 obronił z wyróżnieniem pracę doktorską w specjalności automatyka i robotyka. Od 2001 roku pracuje w firmie Filbico sp. z o.o., obecnie jako dyrektor ds. rozwoju. Doświadczenia Marek Brudka w trakcie pracy na PW oraz w Filbico obejmują prace badawczo-rozwojowe z zakresu robotyki, systemów dowodzenia, zarządzania kryzysowego oraz bezpieczeństwa teleinformatycznego.
Dr inż. Janusz Furtak ukończył Wydział Cybernetyki WAT. Po studiach pracował w Zespole Informatyki Wojsk OPK i uczestniczył w tworzeniu systemów informatycznych na potrzeby namierzania radiowego. Nauczyciel akademicki WAT i uczestnik prac badawczych m.in. trenażera lotów i komputera pokładowego dla samolotu Iryda. Obronił pracę doktorską na temat kalibracji kamery. Instruktor Akademii Sieciowej Cisco z zakresu bezpieczeństwa teleinformatycznego. Aktualnie pełni funkcję Dyrektora Instytutu Teleinformatyki i Automatyki Wydziału Cybernetyki WAT.
Andrzej Stasiak jest ekspertem w dziedzinie projektowania systemów informatycznych (w tym systemów czasu rzeczywistego). Od wielu lat członek komitetów programowych: Krajowej Konferencji Inżynierii Oprogramowania i Konferencji Systemu Czasu Rzeczywistego. Od 1987, jako absolwent i pracownik Wydziału Cybernetyki Wojskowej Akademii Technicznej, prowadzi działalność dydaktyczną i naukowo-badawczą. Doświadczenie zawodowe zyskał kierując, bądź biorąc udział w ramach wielu złożonych projektów informatycznych. Prowadzi również wykłady na Politechnice Warszawskiej oraz innych uczelniach warszawskich.
Jan Chudzikiewicz ukończył studia magisterskie o specjalności systemy komputerowe na Wydziale Cybernetyki Wojskowej Akademii Technicznej. W roku 2001 obronił pracę doktorską uzyskując z obszaru diagnozowania sieci komputerowych. Pracuje w Wojskowej Akademii Technicznej. Jego zainteresowania koncentrują się wokół metod diagnozowania systemów komputerowych, sieci komputerowych i systemów tolerujący błędy, jak również oprogramowania niskopoziomowego dla systemów klasy Windows.
Adam Kozakiewicz jest adiunktem w Naukowej i Akademickiej Sieci Komputerowej. Stopień doktora telekomunikacji otrzymał w 2008 roku na Politechnice Warszawskiej. W pionie Naukowym NASK od 2006 roku, w tym od końca 2008 roku jako kierownik Zespołu Metod Bezpieczeństwa Sieci i Informacji. Zatrudniony także jako adiunkt w Instytucie Automatyki i Informatyki Stosowanej Politechniki Warszawskiej. Zainteresowania naukowe obejmują bezpieczeństwo teleinformatyczne (w tym heurystyczne metody wykrywania zagrożeń), modelowanie ruchu sieciowego, obliczenia równoległe i rozproszone.
Anna Felkner jest absolwentką studiów magisterskich na Wydziale Informatyki Politechniki Białostockiej i studiów doktoranckich na Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej. Obecnie pracuje jako adiunkt w Zespole Metod Bezpieczeństwa Sieci i Informacji Pionu Naukowego NASK. Główne zainteresowania badawcze dotyczą bezpieczeństwa systemów informatycznych, kontroli dostępu i zarządzania zaufaniem.
Marek Małowidzki jest absolwentem Wydziału Elektroniki i Technik
Informacyjnych Politechniki Warszawskiej. Obecnie pracuje
w Wojskowym Instytucie Łączności w Zegrzu, koordynując prace nad bezpieczeństwem i integracją systemów informatycznych, oraz finalizuje pracę doktorską dotyczącą modelowania ruchu w sieciach TCP/IP. Główne zainteresowania zawodowe obejmują systemy i technologie rozproszone, programowanie współbieżne, a także sieci TCP/IP.
