Paweł Goleń, blog

Bezpieczeństwo należy do tej samej klasy wymagań co stabilność, wydajność czy ergonomia aplikacji, czyli do wymagań niefunkcjonalnych. Z tą klasą wymagań jest spory problem, bo często przyjmuje się poniekąd za pewnik, że aplikacja będzie działa stabilnie oraz wydajnie, a przy okazji nie doprowadzi użytkowników do granic wytrzymałości poprzez użycie małej jasnozielonej czcionki na seledynowym tle. Czy klient "domyślnie" dostaje niestabilną, niewydajną aplikację, po której użyciu pracownik trafia do okulisty? Czy klient uszczęśliwiony takim arcydziełem musi dopłacić, by aplikacja dała się używać? No dobrze, częściowo tak. Na przykład wymagania sprzętowe mogą być tak dobrane, by bardzo nieoptymalny kod jakoś dawał radę. Proponuję na etapie negocjacji umowy/projektu poprosić o przykłady testów wydajności, które uzasadniają takie a nie inne wymagania dla sprzętu. Może się okazać, że takich testów po prostu nie ma (co czasami się ukrywa pod stwierdzeniem "tak, mamy takie testy dla jednego z naszych klientów, ale nie możemy ich pokazać, bo klient nie pozwala").

Odnośnie polityki jakości jednej z firm: prawdziwa jakość to więcej niż standard. Ten slogan był zamieszczany w oficjalnych materiałach/prezentacjach. Nawet zespół testerów (od testów funkcjonalnych) z pewną ironią powiesił sobie to hasło, bo, jak łatwo się domyślić, zwykle dostarczana była wersja "standard", czyli taka, w której jakość pozostawia wiele do życzenia... Taka firma rzeczywiście może sobie kazać dopłacić za to, że będzie bezpiecznie. Tylko, że tak nie powinno być, bezpieczeństwo powinno być przewagą konkurencyjną firmy nad innymi, którzy oferują produkty tego samego rodzaju. Dokładnie tak jak obecnie jest w przypadku ogólnie pojętego user experience.

Problemem, według mnie, jest to, że wymagania niefunkcjonalne nie zostają bezpośrednio zawarte w specyfikacji systemu. Z tego powodu wykonawca system tworzy tak, jak mu wygodniej. To musi się zmienić, choćby przez to, że wymagania odnośnie bezpieczeństwa znajdą się w specyfikacji i umowie, tak, by od ich spełnienia zależny był odbiór systemu. Prawda jest taka, że rządzą pieniądze. Inicjatywa trustworthy computing nie wynikała z tego, że Microsoft postanowił być nagle bardzo bezpieczny. Po prostu ówczesna sytuacja (i opinia o firmie) była taka, że zaczął odczuwać wymierne straty finansowe. Dlatego teraz w Microsoft Security Development Lifecycle (SDL) – Process Guidance można przeczytać: All software developers must address security threats. Computer users now require trustworthy and secure software, and developers who address security threats more effectively than others can gain competitive advantage in the marketplace. Also, an increased sense of social responsibility now compels developers to create secure software that requires fewer patches and less security management.

Privacy also demands attention. To ignore privacy concerns of users can invite blocked deployments, litigation, negative media coverage, and mistrust. Developers who protect privacy earn users’ loyalty and distinguish themselves from their competitors.

Secure software development has three elements: best practices, process improvements, and metrics. This document focuses primarily on the first two elements, and metrics are derived from measuring how they are applied. Bezpieczeństwo nie zawiera się w pojęciu jakości. Jednym z założeń SDL odnośnie bezpieczeństwa (zresztą analogicznie odnośnie prywatności) jest:

• secure by design,
• secure by default,
• secure by deployment,

Oznacza to między innymi tyle (bo kwestię domyślnej konfiguracji i wdrożenia sobie odpuszczę), że już przy projekcie aplikacji bezpieczeństwo musi być uwzględnione. Wiąże się to również z modelowaniem zagrożeń oraz określeniem security controls, które spowodują sprowadzenie ryzyk związanych z określonymi zagrożeniami do akceptowalnego poziomu. Co może się stać, gdy tego kroku zabraknie? Może okazać się, że stworzona aplikacja jest na prawdę wysokiej jakości (przynajmniej według części przyjętych metryk), ale nie jest bezpieczna, bo zawiera fundamentalne błędy w architekturze.

Rzeczywiście można obserwować korelację między jakością oraz bezpieczeństwem. W przypadku kodu niskiej jakości (co z kolei może się wiązać z chaotycznym procesem tworzenia oprogramowania) prawdopodobieństwo wystąpienia błędu jest stosunkowo wysokie. Wysokie jest więc również prawdopodobieństwo wystąpienia błędów bezpieczeństwa. Racjonalnie patrząc (nie twierdzę, że wszystkie, lub nawet większość firm patrzy racjonalnie) firmy powinny być zainteresowane poprawą jakości kodu, ponieważ wówczas mniej czasu (i pieniędzy) będą traciły na poprawę błędów wszelkiego rodzaju, w tym błędów bezpieczeństwa.

Oczywiście, jeśli klient zamawia jakiś konkretny mechanizm bezpieczeństwa, to musi za niego zapłacić. Przy czym mówię tutaj już o pewnej funkcji, na przykład implementacja uwierzytelniania kluczem, implementacja autoryzacji przy pomocy kodów SMS, moduł powiadomień o operacjach, (...). Natomiast nie wyobrażam sobie, by dopłacał dodatkowo za prawidłową realizację tych mechanizmów. Dzięki OWASP czy CWE/SANS TOP 25 Most Dangerous Programming Errors pojawia się punkt odniesienia odnośnie tego, co jest prawidłowe, a co nie.

Kilka lat temu uczestniczyłem w procesie wyboru wykonawcy pewnej aplikacji internetowej. W zasadzie każda z firm startujących w "konkursie" przekonywała nas, że ich aplikacja jest bezpieczna. Wynikało to z faktu, że ta aplikacja akurat "intuicyjnie" musiała być bezpieczna. Tak się składało, że jedna z tych firm niewiele wcześniej dostarczyła aplikację, do której bezpieczeństwa miałem poważne zastrzeżenia. Nie omieszkałem wyliczyć ich wszystkich (posłużyłem się wówczas OWASP Top10 2004), co wyraźnie poirytowało pana prezentującego, który poczerwieniał na twarzy, zaczął machać rękami i lekceważyć podatności w owej wcześniejszej aplikacji (tak się składało, że przy tamtym projekcie też uczestniczył). Najbardziej spodobało mi się "tłumaczenie" XSS: i co z tego, że wyskoczy jakieś okienko?!. Na pytanie w jaki sposób w takim razie zapewnią, że programiści, którzy nie potrafili napisać poprawnej aplikacji (popełniali elementarne błędy, które wskazują ewidentnie na ich niewiedzę w temacie bezpieczeństwa aplikacji internetowych), inną aplikację uczynią super bezpieczną, całkiem czerwony na twarzy pan już nie potrafił odpowiedzieć.

Ponawiam pytanie: czy programiści, którzy nie potrafią tworzyć bezpiecznego kodu (lub nie mają takiego nawyku) nagle dostaną olśnienia, bo akurat piszą bankowość internetową lub klient wykupił opcję security included? Wątpię. A pytanie można rozszerzyć na analityków, projektantów, testerów...