Paweł Goleń, blog

Proste z pozoru pytanie często w rzeczywistości jest bardzo skomplikowaną kwestią. Na przykład takie pytanie:

Moje hasło ma 10 znaków, zawiera dużą literę, znak specjalny i cyfrę. Czy jestem bezpieczny?

Pierwszy problem to zrozumienie pytania. O co właściwie chodzi? Co należy rozumieć pod pojęciem "jestem bezpieczny"?

Tak, stosowanie hasła o takich parametrach wskazuje na stosowanie się do tak zwanych dobrych praktyk, choć nawet to nie jest pewne. Bo co, jeśli hasło brzmi:

Dinozaur#1

Rzeczywiście, zawiera duża literę, znak specjalny i cyfrę, ale jednocześnie jest w praktyce hasłem słownikowym, które dodatkowo okraszone zostało końcówką #1 by spełnić ("jakieś głupie") wymagania co do złożoności hasła.

A może hasło jest rzeczywiście bardziej skomplikowane, ale za to zapisane na żółtej karteczce i przyklejone do monitora? Jeśli tak, to czy ten monitor znajduje się w miejscu publicznie dostępnym (biuro w stylu open space), czy może w mieszkaniu samotnika, który nie wpuszcza do domu nikogo? Może jest jeszcze inaczej, zamiast żółtej karteczki na monitorze jest biała kartka w portfelu lub notatka w telefonie?

Właściwie do czego jest to hasło? Kto chciałby je zdobyć? Niech to będzie nawet hasło do bankowości internetowej. Czy ta żółta karteczka to już koniec świata? Nie koniecznie, jeśli tym, czego się obawiasz to Borys albo jakiś inny zdalny atakujący, który chce Cię okraść z odległości kilku tysięcy kilometrów (hipotetyczny scenariusz z włamaniem się do komputera, przejęciem kontroli nad kamerą internetową i odczytanie zawartości żółtej karteczki wspaniałomyślnie pominę). Tylko, że ten hipotetyczny Borys może nie być jedynym problemem, którego powinieneś się obawiać, bo obrobić Cię postanowi nisko opłacany praktykant (open space), albo wynajmowana przez Ciebie sprzątaczka czy opiekunka do dziecka (dom).

Masz skomplikowane hasło, nie zapisałeś go nigdzie. A może Twój komputer jest nie do końca twój? Jesteś pewien, że nie czai się na nim żaden keylogger? Może masz w zwyczaju korzystać, nawet sporadycznie, z komputerów, nad którymi nie masz kontroli? Na przykład w kafejce internetowej podczas wycieczki do Chin?

Jesteś pewny, że Twój komputer jest zabezpieczony prawidłowo, nie ma na nim żadnego malware, a z obcych komputerów nie korzystasz. A może masz brzydki zwyczaj korzystania z tego samego hasła (lub utworzonego na podobnej zasadzie) w wielu różnych serwisach? Na nic Twoje pilnie strzeżone, skomplikowane hasło, jeśli serwis X przechowuje je w formie jawnej i udostępnia każdemu chętnemu, nie koniecznie zgodnie z intencjami jego twórców.

Takie wątpliwości można mnożyć prawie w nieskończoność. A przecież pytanie było takie proste, oczekiwałeś prostej odpowiedzi, TAK lub NIE... Ale prostych odpowiedzi niestety nie ma.

Tworząc aplikację trzeba podjąć decyzję jakie mechanizmy zabezpieczeń zastosować, czasami trzeba porównać kilka możliwych rozwiązań. Przed dokonaniem takiego porównania warto zastanowić się nad kilkoma pytaniami:

• przed czym chcemy się bronić,
• jaki poziom bezpieczeństwa chcemy osiągnąć (inaczej - jaki poziom ryzyka akceptujemy),
• przez kogo będzie wykorzystywane nasze rozwiązanie,
• w jaki sposób typowy użytkownik będzie z niego korzystał,

Ustalenie zagrożeń (tu cały czas mam problem z terminologią), które bierzemy pod uwagę, jest istotne z dwóch powodów. Po pierwsze dlatego, by w rozważaniach uwzględnić wszystkie istotne, typowe zagrożenia. Po drugie po to, by określić, czym się nie zajmujemy. Jest to do pewnego stopnia związane z poziomem bezpieczeństwa, który chcemy osiągnąć. Wykluczenie z rozważań pewnych obszarów (zagrożeń) może wynikać z tego, że uznajemy je za mało prawdopodobne, a ryzyko z nimi związane za akceptowalne.

Nie bez znaczenia pozostaje również to, dla kogo przeznaczony jest tworzony system. Jeśli przesadzimy z zabezpieczeniami potencjalni klienci nie będą chcieli korzystać z naszego systemu, bo będzie dla nich po prostu niewygodny (patrz: Jak badać wygodę mechanizmów bezpieczeństwa?). Późniejsze "poluzowanie" zabezpieczeń nie zawsze będzie możliwe, jeśli coś zostało zaprojektowane do działania jako całość, może nie działać poprawnie, gdy usuniętych zostanie kilka jej elementów. Z drugiej strony nasza grupa docelowa i jej przyzwyczajenia (w tym te odnośnie tego, w jaki sposób i w jakich sytuacjach typowy użytkownik korzysta z naszego systemu) mają wpływ na ryzyko, które chcemy redukować. Być może okaże się, że nasza grupa docelowa ma skłonność do specyficznych, ryzykownych zachowań i fakt ten będzie miał istotny wpływ na analizę ryzyka i jej wyniki.

Kolejną rzeczą, na którą warto zwrócić uwagę, jest odwieczna walka pocisku z pancerzem. Zabezpieczenia (pancerz), który jest skuteczny w tej chwili, może przestać być efektywny, gdy pojawi się nowy atak (pocisk). Dlatego jak mantra powtarzany jest tekst: bezpieczeństwo to nie stan, bezpieczeństwo to proces. Warto na to spojrzeć również w sposób sugerowany w tym wpisie: You Can’t Outrun the Bear, so Let’s Make a Deal. Mówiąc wprost - projektując mechanizmy bezpieczeństwa musimy zadbać o to, by znaleźć się w strefie nieatrakcyjnej dla atakującego, co oznacza tylko tyle, że innych jest łatwiej zaatakować niż nas. Z czasem ci inni prawdopodobnie staną się trudniejszym celem (bo zmienią swój system), więc również i my będziemy musieli dokonać zmian, bo to teraz nas zaczną ścigać niedźwiedzie. Jakich zmian? Takich, jakich będzie wymagała od nas sytuacja, a nie takich, które my będziemy uznawać za sexy. Choć z tym ostatnim to akurat różnie bywa...