II Konferencja i3: internet infrastruktury - innowacje Wrocław,

Transkrypt

1 II Konferencja i3: internet infrastruktury - innowacje Wrocław,

2 Plan prezentacji Wprowadzenie Standardy bezpieczeństwa Funkcjonalność systemu Sposób użycia Kierunki rozwoju, współpraca

3 Wprowadzenie Czy możliwa jest ocena bezpieczeństwa? JAK je oceniać? Making Security Measurable

4 Specyfikacje ułatwiające ocenę bezpieczeństwa Próby ustandaryzowania informacji dotyczących bezpieczeństwa IT Mnogość standardów, za większość z nich odpowiada organizacja MITRE (hyp://mitre.org) Enumeracje (m.in. CVE, CPE, CWE) Języki (np. OVAL, CRF) Repozytoria (np. NVD, Red Hat Repository)

5 CVE CVE = Common Vulnerabilices and Exposures Lista powszechnie znanych podatności (umożliwiających uzyskanie dostępu w sposób bezpośredni - vulnerability oraz pośrednio, mogących prowadzić do kompromitacji systemu - exposure) Udostępniane w postaci XML, HTML, CSV lub TXT Instancja CVE zawiera: Identyfikator (np. CVE ) Rodzaj wpisu ( entry lub candidate ) Krótki opis podatności Odsyłacze (raporty różnych organizacji, identyfikatory OVAL- ID itd.)

6 Name: CVE Status: Entry CVE przykład Reference: BUGTRAQ: XSS Bug in NetScreen- SA 5000 Series of SSL VPN appliance Reference: URL:hYp://marc.theaimsgroup.com/?l=bugtraq&m= &w=2 Reference: FULLDISC: XSS Bug in NetScreen- SA 5000 Series of SSL VPN appliance Reference: URL:hYp://lists.grok.org.uk/pipermail/full- disclosure/2004- March/ html Reference: BUGTRAQ: NetScreen Advisory 58412: XSS Bug in NetScreen- SA SSL VPN Reference: URL:hYp://marc.theaimsgroup.com/?l=bugtraq&m= &w=2 Reference: CERT- VN:VU# Reference: URL:hYp:// Reference: BID:9791 Reference: URL:hYp:// Reference: XF:netscreen- delhomepagecgi- xss(15368) Reference: URL:hYp://xforce.iss.net/xforce/xfdb/15368 Cross- site scripcng (XSS) vulnerability in delhomepage.cgi in NetScreen- SA 5000 Series running firmware 3.3 Patch 1 (build 4797) allows remote authenccated users to execute arbitrary script as other users via the row parameter.

7 CPE CPE = Common Plaworm Enumeracon Ustrukturyzowany schemat nazewnictwa dla systemów i plaworm technologii informacyjnej Dobrze określony format nazw, język do opisu złożonych plaworm Popularne nazwy zebrane w CPE Dicconary Instancja CPE reprezentowana przez URI, zgodnie ze schematem: cpe:/ {part} : {vendor} : {product} : {version} : {update} : {edi;on} : {language} Przykładowo: cpe:/a:zonelabs:zonealarm_internet_security_suite:7.0 cpe:/a:adobe:reader:8.1 cpe:/a:mozilla:firefox: ::osx:zh- tw cpe:/o:microsoy:windows_2000::sp4:pro cpe:/o:microsoy:windows_xp:::pro cpe:/o:redhat:enterprise_linux:4:update4

8 CPE przykład CPE Language <?xml version="1.0" encoding="utf- 8"?> <cpe:plaworm- specificacon xmlns:cpe="hyp://cpe.mitre.org/language/2.0"> <cpe:plaworm id="123"> <cpe:ctle>microsoy Windows XP with Adobe Reader</cpe:ctle> <cpe:logical- test operator="and" negate="false"> <cpe:fact- ref name="cpe:/o:microsoy:windows_xp" /> <cpe:fact- ref name="cpe:/a:adobe:reader" /> </cpe:logical- test> </cpe:plaworm> <cpe:plaworm id="456"> <cpe:ctle>sun Solaris 5.8 or 5.9 or 5.10</cpe:ctle> <cpe:logical- test operator="or" negate="false"> <cpe:fact- ref name="cpe:/o:sun:solaris:5.8" /> <cpe:fact- ref name="cpe:/o:sun:solaris:5.9" /> <cpe:fact- ref name="cpe:/o:sun:solaris:5.10" /> </cpe:logical- test> </cpe:plaworm>

9 CPE przykład CPE Language, cd. <cpe:plaworm id="789"> <cpe:ctle>microsoy Windows XP with Office 2003 or 2007</cpe:ctle> <cpe:logical- test operator="and" negate="false"> <cpe:fact- ref name="cpe:/o:microsoy:windows_xp" /> <cpe:logical- test operator="or" negate="false"> <cpe:fact- ref name="cpe:/a:microsoy:office:2003" /> <cpe:fact- ref name="cpe:/a:microsoy:office:2007" /> </cpe:logical- test> </cpe:logical- test> </cpe:plaworm> </cpe:plaworm- specificacon>

10 CVSS CVSS = Common Vulnerability Scoring System Plaworma wymiany charakterystyk podatności i ich wpływu na infrastrukturę Ocena krytyczności luk w bezpieczeństwie Grupy metryk Base, Temporal, Environmental Dla każdej grupy istnieje metoda wyznaczania punktów określających stopień krytyczności podatności (skala od 0 do 10) Wektor skompresowana reprezentacja wartości podmetryk

11 CVSS grupa metryk Base hyp:// guide.html

12 CVSS grupa metryk Base Wektor: AV:[L,A,N]/AC:[H,M,L]/Au:[M,S,N]/C:[N,P,C]/I:[N,P,C]/A:[N,P,C] Nazwa, oznaczenie Access Vector (AV) Access Complexity (AC) Authenccacon (Au) Confidencality Impact (C) Integrity Impact (I) Availability Impact (A) Możliwe wartości Local (L), Adjacent Network (A), Network (N) High (H), Medium (M), Low (L) Mulcple (M), Single (S), None (N) None (N), Parcal (P), Complete (C) None (N), Parcal (P), Complete (C) None (N), Parcal (P), Complete (C)

13 NVD NVD = Naconal Vulnerability Database Repozytorium danych dotyczących luk w bezpieczeństwie, stanowiące syntezę CVE + CPE + CVSS Zarządzane przez NIST (Naconal Insctute of Standards and Technology) Data Feeds (XML, RSS)

14 Gromadzenie informacji o systemach Podejście statyczne czy dynamiczne? Statyczne: konfiguracja (lista zainstalowanego oprogramowania) podawana przez administratora Dynamiczne: użycie specjalnego agenta, programu uruchomionego na każdym z węzłów, który przesyła informacje o zainstalowanym oprogramowaniu do centralnego węzła

15 Podejście statyczne Podejście statyczne rozumiemy jako ręczne aktualizowanie informacji o zainstalowanym oprogramowaniu Zalety Nie ma żadnej ingerencji w system (bez instalowania dodatkowego oprogramowania, konfiguracji, przyznawania uprawnień itd.) Jeśli można dobrze zdefiniować (zbiór) CPE dla danej maszyny, można zastosować to podejście nawet w przypadku silnie heterogenicznej infrastruktury

16 Wady Podejście statyczne cd. Niewygodne z punktu widzenia administratora maszyny Wymusza stosowanie się do pewnych norm (wpisy zgodne z CPE) Powinno być poparte polityką bezpieczeństwa Większe ryzyko wprowadzenia danych błędnych bądź nieprecyzyjnych

17 Podejście dynamiczne Podejście dynamiczne rozumiemy jako automatyczne aktualizowanie informacji o zainstalowanym oprogramowaniu (poprzez wykorzystanie programów agentów ) Zalety Wygodne z punktu widzenia administratora maszyny Niewielkie ryzyko wprowadzenia błędnych danych

18 Podejście dynamiczne cd. Wady Konieczność instalacji agenta (z odpowiednimi uprawnieniami) Kontrola działania programu agenta i wysyłanych przez niego informacji Skąd wziąć agenta? Stosunkowo łatwo można przygotować skrypt zbierający informacje o pakietach oprogramowania zainstalowanych w różnych dystrybucjach Linuksa, ale w przypadku innych systemów operacyjnych (np. Windows, Solaris) może to być skomplikowane Co z innymi urządzeniami, na przykład sieciowymi? (np. Cisco IOS również wymieniane w CVE hyp://web.nvd.nist.gov/view/vuln/detail? vulnid=cve /) Tylko niektórzy producenci (np. Red Hat) udostępniają repozytoria

19 Które z podejść jest słuszne? Precyzja a zakres zastosowania Wygoda a kompatybilność Żadne z podejść nie jest idealne Więc należy zastosować OBYDWA!

20 System SARA SARA = System Automatycznego Raportowania i Administracji [Bezpieczeństwem Infrastruktury] Wewnętrzny system zaprojektowany dla PCSS Realizowany z użyciem pythonowego środowiska web2py Wykorzystuje repozytorium NVD Może być użyty do inwentaryzacji

21 System SARA status prac System jest rozwijany celem udostępnienia nowych funkcjonalności Podstawowa funkcjonalność jest zrealizowana Zostało przygotowane testowe wdrożenie

22 System SARA główne aspekty funkcjonalności Pobieranie danych dotyczących podatności i składowanie ich w bazie Przechowywanie danych na temat infrastruktury Przeprowadzanie statycznej kontroli bezpieczeństwa (na podstawie pobranych informacji o podatnościach oraz danych na temat infrastruktury) Generowanie raportów (aktualizacje, przeprowadzone kontrole) i rozsyłanie ich do osób odpowiedzialnych za bezpieczeństwo

23 Schemat działania systemu SARA

24 System SARA dane na temat podatności Dane o podatnościach są pobierane z repozytorium NVD, a następnie składowane w specjalnie zaprojektowanej bazie danych W bazie danych przechowywane są informacje o lukach w bezpieczeństwie z uwzględnieniem: Podatnej konfiguracji (w formie prezentowanej przez NVD, wraz z wpisami CPE zdefiniowanymi w języku CPE Language) Metryk CVSS z grupy Base (również udostępniane w NVD) Słownego opisu luki (pochodzącego z CVE) Daty publikacji podatności oraz daty modyfikacji informacji o niej (z CVE) Częstotliwość aktualizacji zależna od konfiguracji systemu SARA (mechanizm Cron podobny do spotykanego w systemach uniksowych)

25 System SARA dane na temat infrastruktury Oprócz zebranych z NVD informacji o podatnościach, system przechowuje dane na temat infrastruktury, dotyczące: Maszyn (urządzeń), z uwzględnieniem maszyn wirtulanych Informacji lokalizacyjnych (np. miejsce, gdzie znajduje się dana maszyna) Administratorów odpowiedzialnych za poszczególne elementy infrastruktury Oprogramowania zainstalowanego w systemach infrastruktury Połączeń sieciowych Luk bezpieczeństwa, które już w infrastrukturze wykryto Statystyk

26 System SARA kontrola bezpieczeństwa System przeprowadza kontrolę bezpieczeństwa infrastruktury poprzez znalezienie dopasowań zgodnie z algorytmem CPE Language Matching (opisanym w specyfikacji CPE) Kontrola może obejmować całą infrastrukturę, jak i wybrane jej elementy Podobnie jak aktualizacje bazy danych, procedura kontroli jest zdefiniowana w mechanizmie Cron

27 System SARA raportowanie System generuje raporty z przeprowadzonych kontroli bezpieczeństwa oraz dokonanych aktualizacji bazy danych Raport aktualizacji zawiera informacje dotyczące poszczególnych wpisów CVE dodanych do bazy danych, jak również błędy występujące podczas procedury Raport skanowania zawiera nazwę maszyny, adres e- mail administratora, słowny opis podatności, link do strony NVD udostępniającej szczegóły podatności Moduł rozsyłania wysyła raporty do: Administratorów infrastruktury (tylko raporty kontroli, dotyczące podległych im elementów infrastruktury) Oficerów bezpieczeństwa (raporty kontroli, raporty aktualizacji)

28 Wykryte problemy

29 Powiązania maszyn z wpisami CPE

30 Wygenerowany raport

31 Przykładowe kierunki rozwoju Wykorzystanie słownika nazw plaworm CPE Dicconary Rozszerzenie funkcjonalności inwentaryzacji (np. lista portali, raporty z audytów) Udoskonalenie modułu raportów (np. oddzielne raporty za wybrany okres, tylko określonych elementów infrastruktury itp.) Przekształcenie na zestaw luźno powiązanych usług (SOA?)

32 Podsumowanie SARA to uzupełnienie dla systemów monitorowania opartych o dynamiczne podejście do zbierania danych System ten może zostać użyty w przypadku gdy nie istnieje odpowiednie oprogramowanie agenta dla systemu operacyjnego węzła Kolejne wersje systemu SARA będą minimalizować pracę administratora oraz zapewnią lepszą integrację

33 Informacje kontaktowe Prelegent PCSS hyp:// Zespół Bezpieczeństwa PCSS hyp://security.psnc.pl

34 Pytania?

35