Zapewne nie tylko w projektowaniu rozwiązań IT nie można mieć wszystkiego. Czy również w zakresie Security czy Usability trzeba wybierać jedno?

Gdy myślimy o tym, w jaki sposób zrealizować wymagania do tworzonego przez nas systemu, często zastanawiamy się, które aspekty powinny być najważniejsze. Na czym się skupić?

Łatwo to zobrazować na poniższym, popularnym diagramie. Najchętniej stworzylibyśmy daną funkcjonalność zgodnie z wymaganiami klienta, łatwą w użyciu i w pełni bezpieczną. 

Jednak w zdecydowanej większości przypadków jest to bardzo trudne. Często wymagania odnośnie bezpieczeństwa utrudniają nam użycie naszego systemu. Z kolei próbując zwiększyć użyteczność, narażamy się na luki w bezpieczeństwie. Ma to szczególne znaczenie w systemach eCommerce, gdzie tak ważne są konwersje i to, żeby strona była jak najprostsza i jak najbardziej intuicyjna. 

Na czym polega konflikt Security vs Usability?

Dobrymi przykładami “utrudnień” w łatwości użytkowania systemu są tutaj:

• wieloskładnikowe logowanie – dodając kolejne składniki do procesu logowanie (kod SMS, weryfikację w aplikacji), zdecydowanie utrudniamy sam proces logowania, jednak w zamian za to otrzymujemy zwiększone bezpieczeństwo konta użytkownika, 
• wymaganie pobierania zgody przetwarzania danych osobowych – jest to wymagane przez GDPR. Od momentu jego wprowadzenia strony internetowe zaczęły zasypywać nas popupami z pytaniem czy wyrażamy zgodę przetwarzanie danych, na cookies itp. Myślę że każdy z nas się już z tym spotkał. To zdecydowanie nie sprzyja szybkiemu przeglądaniu strony.

Jednak czy warto rezygnować z bezpieczeństwa, żeby zyskać lepszą konwersję?

Czy warto skupiać się tylko na jednej właściwości?

Spójrzmy na to z perspektywy relacji pomiędzy tymi właściwościami systemu (funkcjonalność, bezpieczeństwa i użyteczność).

To funkcjonalności, które tworzymy mają prawdziwą wartość biznesową, to one tak naprawdę pozwolą nam (lub naszym klientom) zarabiać pieniądze (lub też oszczędzać czas).

Niestety dobra funkcjonalność do niczego nam się nie przyda, jeżeli będzie utworzona w niebezpieczny sposób. Co z tego, że użytkownicy będą mogli płacić online, jeżeli przy okazji będą mogli podmienić kwotę do zapłaty?

Nawet najbardziej wymyślna funkcjonalność nic nam nie da, jeżeli użytkownicy nie będą potrafili z niej skorzystać (lub też zanim z niej skorzystają, będą musieli przeczytać 20 stron instrukcji). Zastanów się, ile razy sam zaznaczałeś checkbox: “Zapoznałem się z regulaminem”, wcale do tego regulaminu nie zaglądając.

Z kolei najbezpieczniejsze rozwiązanie na nic się zda, jeżeli będzie trudne do użycia. Często mamy tendencje do chodzenia na skróty. Jeżeli będziemy wymagali od naszych użytkowników zmiany hasła co tydzień, wymyślą schemat jak zrobić to prościej. Na przykład dodadzą na jego końcu licznik: hasło1, hasło2, hasło3, … 

Na podstawie przedstawionych przykładów możesz zauważyć, że skupienie się na jednej z podanych właściwości systemu może mieć fatalne skutki dla wartości całej aplikacji. Dlatego tak istotna jest tutaj równowaga, całościowe spojrzenie i zdrowy rozsądek.

Czy nie można mieć wszystkiego? 

Czasem nie można, jednak zawsze warto dążyć do tego, żeby w projektowaniu rozwiązań IT spełniać jak najlepiej wszystkie 3 właściwości.To nie jest tak, że musimy rezygnować z jednego aspektu, żeby wzmocnić inny. Nie. W wielu przypadkach możemy równocześnie zwiększać użyteczność rozwiązania jak i jego bezpieczeństwo. Dlatego powyższy diagram przerysowałbym w następujący sposób.

W tabeli poniżej bardzo wyraźnie widać, jak się kończy ignorowanie jednego lub wielu z tych aspektów systemu.

Widzimy, że dobre bezpieczeństwo mocno zależy od użyteczności. A to dlatego, że bezpieczeństwo zależy od użytkowników końcowych. Nic nam nie dadzą najlepsze wymagania co do poziomu skomplikowania hasła, jeżeli ktoś zapisze je na karteczce przyklejonej do monitora.

Czy da się połączyć security i usability?

Na pewno nie jest to proste, jednak w większości przypadków da się wymyślić rozwiązania, które nie popsują nam dobrego doświadczenia użytkownika w celu zwiększenia poziomu zabezpieczeń.
Poniżej zebrałem kilka zasad, którymi warto się kierować:

• już podczas projektowania myślmy o użyteczności rozwiązań bezpieczeństwa, 
• dajmy wybór użytkownikowi – w przypadku 2FA jedna osoba wybierze kody SMS, a druga aplikacje w telefonie. Warto także wziąć pod uwagę, że nie wszyscy jeszcze korzystają ze smartphoneów, 
• sztuczna inteligencja – może nam pomóc wybrać użytkowników, co do których powinny zostać zastosowane szczególne środki bezpieczeństwa. Możemy na stałe zdefiniować odpowiednie reguły. Dobrym przykładem jest tu mechanizm 3DSecure 2.0. W nowej jego wersji nie wszyscy muszą podlegać dodatkowej weryfikacji. Tylko transakcje podwyższonego ryzyka.
• proste i jasne wytłumaczenie naszych działań – jeżeli potrzebujemy pobrać od użytkownika zgodę na przetwarzanie danych osobowych, to nie zasypujmy go masą prawniczego bełkotu (bez urazy dla prawników). Zamiast tego dużo lepiej będzie w prostych słowach opisać, czemu zbieram tę zgodę i co robię z danymi. Jestem pewien, że taką informację przeczyta więcej osób. Dobrym przykładem jest tu Polityka prywatności Pawła Tkaczyka: https://paweltkaczyk.com/polityka-prywatnosci/
• minimalizacja potrzebnych akcji – jeżeli tworzymy ekosystem naszych usług to zdecydujmy się na single sign on (czyli jedno logowanie do wszystkich usług). To umożliwi pamiętanie tylko jednego hasła, a dzięki temu zwiększamy szansę, że użytkownik użyje silnego hasła w naszym systemie, 
• słuchaj użytkownika – udostępnij możliwość zostawienia swojej opinii, żeby dowiedzieć się, co jest trudne dla użytkownika. Jednak przede wszystkim słuchaj tego co mówi i bierz to pod uwagę przy rozwijaniu systemu.
• monitoruj użycie systemu i konwersję – jeżeli Twoi użytkownicy nie są chętni do podzielenia się swoją opinią, to monitoruj jak działają w systemie. Możesz to zrobić już za pomocą Google Tag Managera.

Podsumowując, zarówno użyteczność jak i bezpieczeństwo tworzonych funkcjonalności jest niezwykle ważne. Warto więc się postarać i tak projektować system, żeby nie utrudnić życia użytkownikom a jednocześnie ich zabezpieczyć.

Podczas szukania źródeł do tego tekstu natknąłem się nawet na konferencję o Usable Security.

Jak widać jest to dość szeroki temat.
https://www.usenix.org/conference/soups2019

To jest post z nowej serii o bezpieczeństwie podczas developmentu. Bardzo chętnie się dowiem co o nim myślisz, bo chciałbym dopasować treści mojego cyklu do Twoich oczekiwań.