Wykorzystanie standardu Common Criteria w ocenie zabezpieczeń oprogramowania do diagnostyki medycznej (case study)

Transkrypt

1 Instytut Technik Innowacyjnych Wykorzystanie standardu Common Criteria w ocenie zabezpieczeń oprogramowania do diagnostyki medycznej (case study) Anna Szymocha, Michał Socha Nr projektu: UDA POIG /08-00 Akronim projektu: CCMODE Plan prezentacji Cel studium przypadku Kontekst studium przypadku Wybrane zagadnienia procesu konstruowania zabezpieczeń Wnioski i podsumowanie 2 1

2 Cel studium przypadku Naszym celem jest próba zastosowania metodyki Common Criteria do rozwoju oprogramowania Wybrano jeden produktów Instytutu EMAG AudioPC Audiometr AudioPC 3 Czym jest AudioPC AudioPC oprogramowanie wspomagającym badanie słuchu AudioPC jest częścią sprzętowo programowego rozwiązania Wspomaga opracowanie audiogramu Wspomaga prowadzenie przesiewowych badań słuchu Archiwizacja wyników 4 2

3 Cechy AudioPC Modularna architektura - elastyczność rozwiązania Możliwość sprawnego przeprowadzania masowych badań Stabilne rozwiązanie sprzętowe audiometr (procesor DSP) Badany bezpośrednio potwierdza punkty audiogramu Produkt jest w końcowej fazie realizacji Audiometr AudioPC 5 Uzasadnienie wyboru przedmiotu studium przypadku Dostęp do dokumentacji projektowej i kodów źródłowych aplikacji Bezpośrednia współpraca z osobami realizującymi AudioPC Znajomość procesu wytwarzania oprogramowania jaki funkcjonuje w Instytucie EMAG 6 3

4 Plan prezentacji Cele studium przypadku Kontekst studium przypadku Wybrane zagadnienia procesu konstruowania zabezpieczeń Wnioski i podsumowanie 7 Zapewnienie dostępności wiedzy Dostęp do kluczowych dokumentów Common Criteria Identyfikacja dokumentów pomocniczych Analiza przykładów i wytycznych opublikowanych na stronach Common Criteria Wyniki innych prac związanych zakresem projektu CCMODE 8 4

5 Narzędzia W pracach będzie wykorzystywany wczesny prototyp wspomagający tworzenie zadania zabezpieczeń (Security Target) Narzędzie docelowo będzie wspomagać konstruowanie zabezpieczeń Ujednolicenie używanego słownictwa 9 Plan prezentacji Cele studium przypadku Kontekst studium przypadku Wybrane zagadnienia procesu konstruowania zabezpieczeń (tworzenia dokumentu ST czyli zadania zabezpieczeń) Wnioski i podsumowanie 10 5

6 Wybór uzasadnionego poziomu zaufania Pierwszym krokiem analizy jest rozważenie uzasadnionego poziomu zaufania, pod kątem którego prowadzona będzie konstrukcja zabezpieczeń. Ze względu na cechy AudioPC, zakładamy poziom zaufania EAL2 Deklaracja zgodności z CC Przedmiot oceny Kolejnym krokiem analizy jest zdefiniowanie przedmiotu oceny (TOE) Dla wyznaczonego przedmiotu oceny prowadzona zostanie identyfikacja problemu bezpieczeństwa Określenie środowiska eksploatacji przedmiotu oceny 12 6

7 Przedmiot oceny Windows.NET XML XSD AudioPC TOE AMGui MS Jet AMCore AMComm Bluetooth Audiometr Baza danych Access Biblioteki 13 Wskazanie identyfikatorów przedmiotu oceny (TOE) autorzy/instytucja opracowująca: Instytut EMAG, CNB nazwa TOE: Audio PC numer wersji TOE:

8 Przegląd możliwości TOE (TOE overview) TOE jest autonomiczną aplikacją działającą w środowisku systemu operacyjnego, wspomagającą badanie słuchu Przeznaczeniem TOE jest wspomaganie personelu medycznego w badaniu słuchu. Badanie to nie ma na celu zdiagnozowania wady słuchu, a jedynie wskazanie osób, których słuch jest w normie. 15 Opis budowy i możliwości TOE (TOE description) TOE składa się z trzech modułów Funkcje TOE zarządzanie bazą pacjentów zarządzanie wynikami badań wspieranie prowadzenia badań 16 8

9 Przedmiot oceny Windows XML XSD.NET AudioPC AMGui TOE MS Jet AMCore AMComm Bluetooth Audiometr Baza danych Access Biblioteki 17 Identyfikacja problemu bezpieczeństwa Zasoby DTO.DanePrzet Dane przetwarzane przez TOE DIT.Audiometr Urządzenie, dzięki któremu przeprowadzane jest badanie słuchu. Na urządzenie składa się mikrokontroler wraz z oprogramowaniem, słuchawki audiometryczne, mikrofon oraz przycisk DIT.DanePom Dane pomiarowe przesłane przez audiometr do TOE DIT.PilkDB Plik bazy danych przechowujący dane pacjentów, wyniki badań wraz z protokołem dostępu MS Jet DIT.Form Pliki xml zawierające treść formularzy elektronicznych Audiometr 18 9

10 Identyfikacja problemu bezpieczeństwa Podmioty SAU.Użytkownik Użytkownik jest przedstawicielem personelu medycznego lub przeszkolonym operatorem. Użytkownik pełni jednocześnie rolę administratora i operatora SAU.Pacjent Osoba badana, przekazująca do TOE informacje o przebiegu badania SNA.Atakujący Osoba, która działa z zamiarem uszkodzenia TOE lub spowodowania wadliwego funkcjonowania. Atakujący działający z zamiarem nieautoryzowanej modyfikacji zbiorów danych SNH.CzynnZewn Nieprzewidywalne czynniki zewnętrzne mogące sprawić uszkodzenie lub błędne funkcjonowanie TOE 19 Specyfikacja problemu bezpieczeństwa Zagrożenia Polityka bezpieczeństwa Założenia Cele zabezpieczeń na TOE Cele zabezpieczeń na otoczenie Funkcjonalne wymagania bezpieczeństwa (SFR) Wymagania uzasadniające zaufanie (SAR) Zdefiniowanie funkcji zabezpieczających 20 10

11 Problem bezpieczeństwa Definicja problemu bezpieczeństwa sprowadza się do identyfikacji: zagrożeń (Threats) reguł polityki bezpieczeństwa (Organizational Security Policies) założeń (Assumptions) Dla każdego z elementów problemu bezpieczeństwa: należy przeprowadzić identyfikację należy uszczegółowić zidentyfikowany element należy zaproponować nazwę zgodną ze spójnym schematem nazw 21 Zagrożenia TDA.NAutDostBD Nieautoryzowany dostęp do bazy danych TIT.BrakZasilania Brak lub za niskie napięcie zasilania audiometru TPH.HałasTła Zbyt wysoki poziom hałasu tła TDA.NAutModKodu Nieautoryzowana modyfikacja kodu wykonywalnego programu TPH.BdZapDanych Błąd zapisu danych TDA.ModXmlXsd Nieautoryzowana modyfikacja plików XML lub XSD TDA.NAutDostSysOp Nieautoryzowany dostęp do systemu operacyjnego TIT.CzynnZewn Nieprzewidziane czynniki zewnętrzne 22 11

12 Wybrane zagrożenia TDA.NAutDostBD Atakujący [Sparam <= SNA.Atakujący] może korzystając z dostępu do bazy danych [Dparam <= DIT.PlikDB] z pominięciem TOE modyfikować, fałszować, usuwać zapisane wyniki badań lub dodawać wyniki badań TIT.BrakZasilania W trakcie badania przez badającego [Sparam <= SAU.Użytkownik] pacjenta [Sparam <= SAU.Pacjent] może wystąpić zbyt niskie napięcie zasilania audiometru [Dparam <= DIT.Audiometr], co spowoduje przerwanie badania i utratę częściowo zebranych wyników [Dparam <= DIT.DanePom, DIT.DanePrzet] TPH.HałasTła Hałas występujący w pomieszczeniu może uniemożliwić przeprowadzenie badania lub sfałszowanie przesyłanych do TOE wyników badań [Dparam <= DIT.DanePom] 23 Reguły polityki bezpieczeństwa Polityka bezpieczeństwa to zbiór reguł, procedur i praktyk narzucanych przez TOE przestrzeganych w instytucji Cele zabezpieczeń TOE zostały sformułowane jedynie na podstawie zagrożeń, dlatego zaniechano specyfikacji elementów polityki bezpieczeństwa 24 12

13 Założenia APH.PrzepBad przeprowadzanie badań APH.BezpFiz TOE ma zapewnione bezpieczeństwo fizyczne APR.WiedzUżytk użytkownicy posiadają odpowiednią wiedzę APH.OprogLic używane oprogramowanie jest licencjonowane APH.StAudio audiometr jest sprawny AIT.ZnCzasu otoczenie dostarcza do TOE poprawne znaczniki czasu AIT.SysOp działający system operacyjny 25 Wybrane założenie APH.PrzepBad Pomieszczenie, w którym przeprowadzane są badania przesiewowe słuchu musi spełniać szereg warunków: wyciszenie (hałas zewnętrzny nie może przeszkadzać w badaniu), rozmiar pomieszczenia powinien uniemożliwiać zakłócanie transmisji bluetooth, dostęp do pomieszczenia powinien być kontrolowany. Badający [Sparam <= SAU.Użytkownik] powinien obserwować pacjenta [Sparam <= SAU.Pacjent] w trakcie badania 26 13

14 Cele bezpieczeństwa Zagrożenia Polityka bezpieczeństwa Założenia Cele bezpieczeństwa dla TOE Cele bezpieczeństwa na otoczenie Funkcjonalne wymagania bezpieczeństwa (SFR) Wymagania uzasadniające zaufanie (SAR) Zdefiniowanie funkcji zabezpieczających 27 Cele bezpieczeństwa Po określeniu przedmiotu oceny i problemu bezpieczeństwa należy przystąpić do wyspecyfikowania celów bezpieczeństwa. Cele zostały zdefiniowane w dwóch zbiorach: Cele zabezpieczeń na TOE Cele zabezpieczeń na otoczenie Pokrywając problem bezpieczeństwa celami zabezpieczeń przestrzegano zasady, że każdy cel pokrywa przynajmniej jedno zagrożenie, założenie lub regułę polityki bezpieczeństwa, a każde zagrożenie, założenie lub reguła polityki bezpieczeństwa jest pokryte przez przynajmniej jeden cel

15 Pokrycie problemu bezpieczeństwa celami bezpieczeństwa Zagrożenie, założenie TIT.BrakZasilania TPH.HałasTła TDA.NAutDostBD APH.PrzepBad Cel bezpieczeństwa O.OdczytNap O.OdczytHałasu O. AutUżytk OE:LogowSysOp OE.CiszaPom OE.ZakłóceniaBT 29 Cele bezpieczeństwa dla przedmiotu oceny O.OdczytNap Informacje o stanie zasilania w audiometrze muszą być przekazywane do TOE O.OdczytHałasu Informacja o poziomie hałasu jaki panuje podczas prowadzenia badania musi być dostarczona do TOE O.AutUżytk W TOE musi być przeprowadzana identyfikacja i autoryzacja użytkowników, którzy otrzymują uprawnienia do odczytu i edycji danych, co zapewnić ma, że tylko uprawnieni użytkownicy będą mogli wykonywać te czynności 30 15

16 Cele bezpieczeństwa dotyczące środowiska OE.CiszaPom Pomieszczenie, w którym są przeprowadzane badania musi być wyciszone OE.ZakłóceniaBT Charakter pomieszczenia ma uniemożliwiać zakłócanie pracy audiometru OE.LogSysOp Przeprowadzana musi być identyfikacja i autoryzacja użytkowników logujących się do systemu operacyjnego, która zapewni, że tylko uprawnieni użytkownicy będą mieli bezpośredni dostęp do bazy danych TOE. 31 Uzasadnienie pokrycia problemu bezpieczeństwa celami Specyfikacja celów bezpieczeństwa wymaga uzasadnienia (ang. rationale) czyli wykazania, że: wobec wszystkich zagrożeń podjęto środki zaradcze, wszystkie zasady polityki bezpieczeństwa będą wymuszane, przyjęte założenia będą podtrzymywane przez wyspecyfikowanie odpowiednich celów środowiskowych

17 Specyfikacja wymagań bezpieczeństwa Zagrożenia Polityka bezpieczeństwa Założenia Cele zabezpieczeń na TOE Cele zabezpieczeń na otoczenie Funkcjonalne wymagania bezpieczeństwa (SFR) Wymagania uzasadniające zaufanie (SAR) Zdefiniowanie funkcji zabezpieczających 33 Specyfikacja wymagań bezpieczeństwa SFR Sprowadza się do wyrażenia celów bezpieczeństwa podanych dla TOE za pomocą funkcjonalnych wymagań bezpieczeństwa (SFR) Cel dla TOE SFR Opis SFR O.AutUżytk FDP_ACC.2 FDP_ACF.1 Complete access control Security attribute based access control O.OdczytNap EXT_FRU_RSA.1 Minimalny poziom zasobów O.OdczytHałasu EXT_FRU_RSA.2 Maksymalny poziom hałasu 34 17

18 Zdefiniowanie dodatkowej rodziny Nie udało się wyrazić dwóch celów wymaganiami funkcjonalnymi wziętymi wprost z normy Druga część CC zawiera rodzinę FRU_RSA, której komponenty są najbliższe by wyrazić cele dla TOE Na bazie rodziny FRU_RSA została zdefiniowana rodzina EXT_FRU_RSA z dwoma komponentami 1 EXT_FRU_RSA: Extended Resource allocation 2 35 Zdefiniowane komponenty ETX_FRU_RSA.1 Minimalny poziom zasobów, który wprowadza wymaganie dla mechanizmów przydziału limitów zasobów, aby te zapewniały użytkownikom i podmiotom minimalny poziom zasobów ETX_FRU_RSA.2 Maksymalny poziom hałasu, który wprowadza wymaganie dla specjalistycznych mechanizmów, aby te nie pozwalały przeprowadzać badań pacjentów gdy poziom hałasu przekroczył określony poziom 36 18

19 Specyfikacja funkcji zabezpieczających Zagrożenia Polityka bezpieczeństwa Założenia Cele zabezpieczeń na TOE Cele zabezpieczeń na otoczenie Funkcjonalne wymagania bezpieczeństwa (SFR) Wymagania uzasadniające zaufanie (SAR) Zdefiniowanie funkcji zabezpieczających 37 Zdefiniowanie funkcji zabezpieczających Funkcjonalne wymagania bezpieczeństwa należy zaimplementować w postaci funkcji zabezpieczających TOE (ang. TSF) SFR Funkcje zabezpieczające TOE FDP_ACC.2 FDP_ACF.1 SFDP.OchronaZasobów EXT_FRU_RSA.1 SFRU.MinPoziomBaterii EXT_FRU_RSA.2 SFRU.MaksPoziomHałasu 38 19

20 Specyfikacja wymagań bezpieczeństwa Zagrożenia Polityka bezpieczeństwa Założenia Cele zabezpieczeń na TOE Cele zabezpieczeń na otoczenie Funkcjonalne wymagania bezpieczeństwa (SFR) Wymagania uzasadniające zaufanie (SAR) Zdefiniowanie funkcji zabezpieczających 39 Komponenty uzasadniające zaufanie Dla zakładanego poziomu EAL podaje się zestaw komponentów uzasadniających zaufanie Assurance Requirements Class ADV: Development Class AGD: Guidance documents Class AVA: Vulnerability assessment ADV_ARC.1 Security Architecture Description ADV_FSP.2 Security-enforcing functional specyfication ADV_TDS.1 Basic design AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures AVA_VAN.2 Vulnerability analysis 40 20

21 Komponenty uzasadniające zaufanie Assurance Requirements ALC_CMC.2 Use of a CM system Class ALC: Life-cycle support ALC_CMS.2 Parts of the TOE CM coverage ALC_DEL.1 Delivery Procedures ALC_FLR.1 Basic Flaw Remediation ATE_COV.1 Evidence of coverage Class ATE: Tests ATE_FUN.1 Functional testing ATE_IND.2 Independent testing - sample 41 Plan prezentacji Cel studium przypadku Kontekst studium przypadku Wybrane zagadnienia procesu konstruowania zabezpieczeń Wnioski i podsumowanie 42 21

22 Wnioski i podsumowanie Przejście przedstawionej ścieżki dla wszystkich zidentyfikowanych zagrożeń i założeń Opracowanie materiału dowodowego wynikającego z komponentów uzasadniających zaufanie Wykorzystanie prototypu narzędzia wspomagającego konstruowanie zabezpieczeń 43 Dziękujemy z uwagę Zapraszamy na kawę 44 22