Automatyczne testowanie infrastruktury pod kątem bezpieczeństwa. Leszek Miś IT Security Architect RHCA,RHCSS,Sec+ Linux Polska Sp. z o.o.

Transkrypt

1 Automatyczne testowanie infrastruktury pod kątem bezpieczeństwa. Leszek Miś IT Security Architect RHCA,RHCSS,Sec+ Linux Polska Sp. z o.o. 1

2 Fakty Są 3 rodzaje serwerów: Zabezpieczone Niezabezpieczone Podobno zabezpieczone Systemy: Strategiczne/krytyczne Publiczne/lokalne 2

3 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 4 Fakty

5 Problemy W jaki sposób być na bieżąco z CVE dla całej infrastruktury? MS Microsoft Internet Explorer CCaret Use-After-Free Linksys WRT110 Remote Command Execution IBM AIX 6.1 / Local root Privilege Escalation OSX <= 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

6 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

7 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

8 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

9 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

10 Testy penetracyjne Kontrolowany atak na zamówienie 10

11 Testy penetracyjne Bezpieczeństwo: Aplikacji Baz danych OS Sieci innych 11

12 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 13 Przedstawienie raportu z audytu bezpieczeństwa konfiguracji systemu RHEL.

14 Pokaz skanowania sieci pod kątem podatności i analiza raportu. 14

15 Skanowanie 15

16 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 17 Omówienie przejęcia kontroli nad infrastrukturą IT organizacji: APT

18 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

19 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

20 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

21 Dziękujemy za uwagę. Leszek Miś IT Security Architect RHCA,RHCSS,Sec+ Linux Polska Sp. z o.o. 21