Czy security through obscurity jednak działa?

Jedno zdanie, dwa różne znaczenia

„Security through obscurity” zwykle tłumaczy się jako bezpieczeństwo przez ukrycie. NIST przywołuje zasadę Kerckhoffsa: bezpieczeństwo kryptosystemu powinno opierać się na tajności klucza, nie tajności algorytmu.^[1] W praktyce pod ten termin wrzuca się dwa różne pomysły. Pierwszy to ukrywanie algorytmu lub mechanizmu, od którego zależy bezpieczeństwo. Drugi to dodatkowe utrudnienie rozpoznania systemu: mniej oczywista ścieżka administracyjna, ograniczenie informacji w banerze, niestandardowy układ usługi.

Pierwszy pomysł jest słaby, bo system powinien wytrzymać publikację projektu i analizę przez niezależnych badaczy. Kryptografia dobrze działa właśnie dlatego, że algorytm może być publiczny, a tajny pozostaje klucz. Drugi pomysł może mieć wartość operacyjną, ale tylko jako warstwa obok poprawnej kontroli dostępu.

Co ciekawego wnosi dyskusja na Lobsters?

Uczestnicy sporu na Lobsters nie zgadzają się co do nazwy, ale ale w jednym punkcie są blisko: ukrycie nie powinno być jedyną barierą. W dyskusji pada praktyczny przykład: zmiana portu SSH może zmniejszyć „background noise”, lecz nie chroni przed kimś, kto już zna poświadczenia lub celowo rozpoznaje usługę.^[2] Zwolennicy bardziej pragmatycznego podejścia wskazują, że atakujący też ma ograniczony czas. System, którego nie znajdzie automatyczny skaner, może nie trafić do masowego ataku. Krytycy odpowiadają, że niestandardowość podnosi koszt obrony, utrudnia monitoring i może wyłączyć gotowe mechanizmy bezpieczeństwa.

Oba argumenty są prawdziwe. Problem zaczyna się wtedy, gdy organizacja liczy „nikt tego nie zauważy” jako pełną kontrolę. Profesjonalny atak ukierunkowany może poświęcić czas na rozpoznanie. Automatyczny skaner może być tylko pierwszym etapem.

Przykład: SSH na innym porcie

Przeniesienie SSH z portu 22 na inny port zwykle zmniejsza liczbę losowych prób logowania i hałas w logach. To może ułatwić analizę prawdziwych zdarzeń. Nie zastępuje jednak kluczy, wyłączenia niepotrzebnego logowania hasłem, ograniczenia użytkowników, aktualizacji i zapory. Skaner może przeskanować wszystkie porty. Człowiek może znaleźć usługę po banerze, konfiguracji DNS albo obserwacji ruchu.

Co gorsza, niestandardowy port może osłabić lokalne zabezpieczenia albo dokumentację. Nowy administrator może nie wiedzieć, gdzie nasłuchuje usługa. Narzędzie monitorujące może sprawdzać tylko standardowy port. Warstwa, która miała dodać tarcie napastnikowi, tworzy tarcie dla zespołu.

Lepszy test niż „czy to działa?”

Usuń tymczasowo element ukrycia z modelu zagrożenia i zapytaj: czy nadal działa uwierzytelnianie, autoryzacja, segmentacja, aktualizacje i monitoring? Jeśli odpowiedź brzmi „nie”, nie masz warstwy defense in depth. Masz pojedynczy punkt awarii.

Następnie policz koszt utrzymania: kto pamięta niestandardowe ustawienie, kto je testuje, jak wykryjesz zmianę i jak odtworzysz konfigurację po awarii? Dobra warstwa obrony musi być obserwowalna. Tajemnica, o której nie wie nawet zespół obrony, jest problemem operacyjnym.

Gdzie ukrycie ma sens?

• Redukowanie automatycznego hałasu, gdy podstawowe mechanizmy już działają.
• Ograniczenie informacji w banerach i komunikatach, jeśli nie psuje diagnostyki.
• Rozdzielenie publicznych i administracyjnych punktów wejścia.
• Honeypoty i fałszywe zasoby, które mają wykrywać rozpoznanie, a nie chronić właściwy system.

W każdym przypadku trzeba założyć, że napastnik w końcu odkryje konfigurację. Jeśli po tym odkryciu system nadal jest bezpieczny, ukrycie było dodatkiem. Jeśli nie, trzeba wrócić do fundamentów.