Automatyczne testowanie infrastruktury pod kątem bezpieczeństwa. Leszek Miś IT Security Architect RHCA,RHCSS,Sec+ Linux Polska Sp. z o.o. 1
Fakty Są 3 rodzaje serwerów: Zabezpieczone Niezabezpieczone Podobno zabezpieczone Systemy: Strategiczne/krytyczne Publiczne/lokalne 2
Fakty Rozbudowane infrastruktury wymagają narzędzi Bez dedykowanych systemów aktywnie skanujących infrastrukturę nie jesteśmy w stanie dowiedzieć się na czas o wystąpieniu podatności Czas administratorów vs nieograniczony czas atakujących Pomijanie aspektów bezpieczeństwa we wczesnej fazie projektów Zagrożenia kryją się w każdej warstwie ekosystemu 3
4 Fakty
Problemy W jaki sposób być na bieżąco z CVE dla całej infrastruktury? MS13-069 Microsoft Internet Explorer CCaret Use-After-Free Linksys WRT110 Remote Command Execution IBM AIX 6.1 / 7.1 - Local root Privilege Escalation OSX <= 10.8.4 - Local Root Priv Escalation (py) VMWare Setuid vmware-mount Unsafe popen(3) Linux Kernel 'MSR' Driver Local Privilege Escalation Solaris Recommended Patch Cluster 6/19 Local root on x86 HP ProCurve Manager SNAC UpdateCertificatesServlet File Upload HP SiteScope Remote Code Execution Microsoft SharePoint 2013 (Cloud) - Persistent Exception Handling Web Vulnerability 5
Problemy Czy jesteś w stanie podliczyć wszystkie urządzenia sieciowe w sieci? Ile z nich posiada interfejs webowy? Ile z nich posiada domyślne ustawienia? Czy potrafisz wykryć syndromy ataku lub jego początkowej fazy? Bezpieczeństwo platform wirtualizacyjnych cloud 6
Potrzeby Bezpieczeństwo jako proces, a nie jako kolejne urządzenia komercyjnego vendora Stale budowana świadomość Dostęp do aktualizowanych na bieżąco baz podatności typu: Zaawansowane narzędzia, umiejętności i usługi Ustanadryzowana konfiguracja systemowa Testy penetracyjne identyfikacja słabych punktów: Dedykowane per nowy projekt Okresowe/automatyczne 7
Potrzeby czyli minimalizowanie ryzyka Metodyka systemowej analizy bezpieczeństwa Centralna konfiguracja i możliwość sprawdzenia poprawności założeń polityki Audyt przystosowania systemów do spełniania standardów bezpieczeństwa STIG/PCI DSS/CIS Audytowanie integralności systemu plików i poprawności konfiguracji Testowanie bezpieczeństwa aplikacji webowych SDLC bezpieczeństwo w fazie projektowej Inwentaryzacja środowiska Aktywny monitoring DNS! 8
Rekomendacja D 9.17: Bank powinien monitorować sieci teleinformatyczne, komponenty infrastruktury teleinformatycznej, usługi sieciowe i systemy informatyczne pod kątem ich bezpieczeństwa 9.19: Eksploatowane w banku drukarki wykorzystywane do drukowania dokumentów zawierających informacje o wysokim stopniu poufności powinny być zabezpieczone przed możliwością wycieku informacji 9.21: Konfiguracja komponentów infrastruktury teleinformatycznej powinna podlegać okresowej weryfikacji pod kątem pozostałych zmian zachodzących w tym środowisku, a także ujawnianych luk bezpieczeństwa. 18.7: Szczególną uwagę bank powinien poświęcić identyfikacji istniejących podatności środowiska teleinformatycznego (w tym komponentów infrastruktury teleinformatycznej) oraz zagrożeń, które mogą je wykorzystać 9
Testy penetracyjne Kontrolowany atak na zamówienie 10
Testy penetracyjne Bezpieczeństwo: Aplikacji Baz danych OS Sieci innych 11
Systemowy standard bezpieczeństwa STIG Security Technical Implementation Guide Obowiązkowy standard dla systemów DoD Wiele punktów kontrolnych: + Dobre praktyki Restrykcyjne uprawnienia Wykrywanie błędów konfiguracyjnych Specyficzne audytowanie Kontrole dostępu (SELinux) Zarządzanie uzytkownikami 12
13 Przedstawienie raportu z audytu bezpieczeństwa konfiguracji systemu RHEL.
Pokaz skanowania sieci pod kątem podatności i analiza raportu. 14
Skanowanie 15
Narzędzia i umiejętności Obowiązkowe narzędzia pentestera: Backtrack/Kali Linux Metasploit Nmap/amap/vmap ZAP/Burp Proxy air*tools Wiele, wiele innych 16
17 Omówienie przejęcia kontroli nad infrastrukturą IT organizacji: APT
APT DDOS na serwery strony logowania banku W międzyczasie: Spear phishing Zainfekowany PDF/podatność w IE Stacja przesiadkowa do skanowania sieci Dodanie funkcji keyloggera do putty Uzyskanie haseł do serwerów Wykrycie serwerów bazodanowych Ukrycie w mikrokontrolerze klimatyzacji 18
Podsumowanie Rekomendacja D wymaga dodatkowych nakładów Zarządzanie i kontrola zmian Analiza incydentów i korelacja zdarzeń Kontrola integralności plików Audyty i testy penetracyjne Zwiększanie poziomu bezpieczeństwa usług, systemów i aplikacji - utwardzanie Szkolenia w pakiecie 19
Security - szkolenia Red Hat IdM jako kontroler domeny linuksowej na bazie IPA Server ModSecurity - skuteczna ochrona aplikacji webowych WALLF Web Gateway - instalacja, konfiguracja, zarządzanie RH413 Red Hat Enterprise Server Hardening RHS429 SELinux Policy Administration Puppet Enterprise Splunk 20
Dziękujemy za uwagę. Leszek Miś IT Security Architect RHCA,RHCSS,Sec+ Linux Polska Sp. z o.o. 21