Paweł Goleń, blog

Jeśli popatrzymy na funkcjonalność systemu, wygodę jego użytkowania i bezpieczeństwo to łatwo zauważymy, że funkcjonalność i wygoda jest "przeciwstawna" bezpieczeństwu. System z mniejszą ilością funkcji jest zwykle bezpieczniejszy (mniejsza szansa popełnienia błędu), a każda funkcja bezpieczeństwa wiąże się z jakimś kosztem. Nie zawsze jest to widoczne dla użytkownika. Użytkownik raczej nie zauważy ASLR, DEP, W^X czy kanarków dodawanych przez kompilator (choć przynajmniej część z tych rozwiązań będzie miało jakiś wpływ choćby na wydajność systemu), to każda funkcja wymagająca akcji od użytkownika (logowanie, podejmowanie decyzji w odpowiedzi na pytanie systemu) będzie już dla niego zauważalna.

W wielu przypadkach funkcja bezpieczeństwa/interakcja z użytkownikiem jest zaprojektowana rzeczywiście źle. Wystarczy wspomnieć "dziwne" polityki haseł, całkowicie niezrozumiałe dla użytkownika komunikaty, wymaganie od użytkownika podjęcie (jakiejś) decyzji bez dostarczenia mu wymaganych do jej podjęcia informacji... Tak, "bezpieka" ma wiele za uszami. Ale...

Problem pojawia się wtedy, gdy biznes chce "upraszczać" (czasami przez ich kompletną eliminację) funkcje związane z bezpieczeństwem. Oczywiście bez jakiejkolwiek wiedzy merytorycznej i zrozumienia jakie ryzyka dana kontrola (w sensie security control) adresuje. Uzasadnienie? Bo skoro za mało klientów z czegoś korzysta to na pewno oznacza, że aplikacja jest za trudna, a jest na pewno za trudna przez te funkcje bezpieczeństwa.

No niestety, nie tędy droga. Obie strony, i bezpieka, i biznes powinny się czegoś nauczyć. Bezpieczeństwo nie jest celem samym w sobie. Nie chodzi też o to, by być absolutnie bezpiecznym tylko wystarczająco bezpiecznym. Po to, by ryzyko mieściło się w "apetycie na ryzyko" danej organizacji. I, niespodzianka, to nie "bezpieka" ten apetyt ustala. Jeśli chodzi o rozwiązania techniczne - trzeba się najpierw zastanowić co chcemy osiągnąć (jakie kontrole powinny być wykorzystane) a dopiero później - jak (jak te kontrole powinny być zaimplementowane/realizowane). Uwierzytelnienie jest kontrolą, ale sposobów jej implementacji jest wiele. Niektóre z nich będą bardziej uciążliwe dla użytkownika, a jednocześnie wcale nie będą bardziej efektywne, system w wyniku ich zastosowania wcale nie stanie się bezpieczniejszy.

Przy zastanawianiu się "jak" trzeba pamiętać kto będzie korzystał z danego systemu. Niestety, najpiękniejsze nawet rozwiązanie (techniczne) nie będzie działać, jeśli użytkownicy go nie zaakceptują. Jest nawet na to CWE-655: Insufficient Psychological Acceptability. Wcale nie takie odkrywcze:

The software has a protection mechanism that is too difficult or inconvenient to use, encouraging non-malicious users to disable or bypass the mechanism, whether by accident or on purpose.

Ile razy wyłączyliście jakąś funkcję bezpieczeństwa? A jeśli jej się nie dało wyłączyć, ile razy kliknęliście "Yes" nawet bez czytania komunikatu, który został wyświetlony?

Z drugiej strony biznes - należy poświęcić trochę czasu na zidentyfikowanie rzeczywistych problemów, bo bardzo często problemem jest coś innego niż się pierwotnie wydaje. Tak, można się tutaj odwołać do 5 Whys. Można również poprosić o feedback klientów, tylko błagam - w tym przypadku niech pytania będą przygotowane w sposób profesjonalny. Za dużo razy widziałem inicjatywy "usprawnień", w których pytania zadawane w ankiecie w sposób jednoznaczny sugerowały odpowiedź. Na pierwszy rzut oka było widać, że autor inicjatywy już znalazł "winnego" i jedyne czego poszukiwał to poparcia swojego przeświadczenia. Już zupełnie pominę fakt, że o tą samą rzecz można zapytać na kilka sposobów, a odpowiedź będzie zależała od sformułowania pytania.

Dobrym rozwiązaniem może być A/B testing czy porównanie dwóch prototypów/makiet symulujących interakcję człowieka z systemem. Takie eksperymenty nie powinny być ograniczone wyłącznie do interakcji z mechanizmem bezpieczeństwa. Jeśli oczekujemy, że użytkownik wykona w jakimś procesie 5 kroków i tylko jeden z nich jest związany z funkcją bezpieczeństwa to może się okazać, że użytkownicy mają problemy z zupełnie czymś innym niż tym nieszczęsnym wpisaniem hasła czy kodu SMS albo niewygodnym CAPTCHA.

I na koniec, drogi biznesie, musisz przyjąć do wiadomości, że czasami to Twoja oferta jest po prostu do niczego...