Poziom bezpieczeństwa wiąże się także z modelami oferowania oprogramowania i wynikającymi z nich motywacjami dostawców.

Oczekiwania dotyczące jakości i bezpieczeństwa oprogramowania stale rosną. Zarówno w biznesie, jak i prywatnie coraz mniej jesteśmy skłonni wybaczać twórcom oprogramowania ich potknięcia, nawet te drobne. Biorąc rozbrat z procesami manualno-papierowymi, staliśmy się całkowicie i nieodwołalnie zależni od dostępności i poprawności informacji w formie elektronicznej, a także od zdolności oprogramowania do ochrony informacji.

Zobacz również:

• Dzięki tej umowie polska policja zyska wiedzę i narzędzia zapobiegające cyfrowym zagrożeniom
• Niebotyczne ceny eksploitów zero-day
• Uwierzytelnianie bez haseł – 10 rozwiązań

Niestety, nasza zdolność do zapewnienia oprogramowaniu którejkolwiek z tych pożądanych cech niewiele się poprawiła. Być może dlatego, że w przeciwieństwie do budownictwa czy innych dziedzin inżynierskich bezpieczeństwo oprogramowania wciąż rozpatrywane jest w kontekście wielkości pierwotnego wydatku, a nie kosztów alternatywnych wynikających ze słabości zabezpieczeń, czy też całkowitych kosztów posiadania uwzględniających dodawanie zabezpieczeń post factum. Czy nadzieje na pozytywne zmiany są uzasadnione?

Automat to nie wszystko

Patrząc wstecz, poprawa jakości i bezpieczeństwa produktu następowała wraz z jego standaryzacją, a także automatyzacją jego wytwarzania. W przypadku oprogramowania biznesowego standaryzacja to w praktyce niedoścignione marzenie. Jeśli idzie o automatyzację, elementy składowe wytwarzane są wprawdzie w fabryce pod (załóżmy) adekwatną kontrolą jakości, ale wciąż przez ludzi. Co gorsza, ostateczny montaż wykonywany jest już w warunkach manufaktury, nikomu nie ujmując.

Automatyzacja wytwarzania produktów jednostkowych doczekała się automatyzacji w postaci systemów CAD/CAM, dzięki którym projekt jest automatycznie przekładany na wsad do wykonania przez taką czy inną obrabiarkę. Analogią w sferze oprogramowania są platformy procesowe, które na podstawie projektów formalnych, np. w standardzie BPMN czy BPEL, uruchamiają proces na dedykowanej „maszynie” wykonawczej. Choć to z pewnością znacznie bezpieczniejsza i tańsza metoda rozwoju oprogramowania, wypada zaznaczyć, że nie dotyczy wszystkich kategorii rozwiązań.

Jest znamienne, że kontrola jakości, zarówno produktów fizycznych, jak i oprogramowania, daje się skutecznie zautomatyzować tylko w pewnym zakresie. Kluczowe decyzje jakościowe nadal pozostają w gestii człowieka. Według różnych ocen, automatyczne testowanie oprogramowania obejmuje raptem 30–40% niezbędnych procedur. W organizacjach stosujących solidną praktykę w dziedzinie wielokrotnego użycia istniejącego (i przetestowanego) kodu można założyć, że kolejnych 10% procedur testowych, a więc sumarycznie ok. 50%, nie wymaga człowieka – to nadal duże uproszczenie, również w kategoriach kosztowo-finansowych.

Wymagania + rozsądek

Co z pozostałymi 50%? Jakość i bezpieczeństwo oprogramowania jako ostatecznego produktu użytkowego nie zależy wyłącznie od programistów. Istotną rolę odgrywają wymagania obejmujące w sposób wyraźny i jednoznaczny kwestie bezpieczeństwa. Co oczywiste, projekt formalny powinien stanowić odzwierciedlenie tych wymagań. Poprawa jakości i bezpieczeństwa na tym poziomie jest najłatwiejsza i najskuteczniejsza, a jednocześnie najmniej kosztowna. Choć to truizm, aplikacje zaprojektowane z myślą o bezpieczeństwie wcale nie stanowią większości. Czy to dlatego, że bezpieczeństwo, jak wszystko, wymaga dodatkowego czasu i środków? Zapewne, choć w tym wypadku koszty to rzecz względna.

Jeśli projekt nie przewiduje ograniczania uprawnień i ich standaryzacji w ramach ról, analogiczną funkcjonalność trzeba będzie zapewnić oprogramowaniem zewnętrznym – wdrażanym i integrowanym oddzielnie, a więc znacznie drożej. Analogicznie, jeśli aplikacja nie weryfikuje treści zapytań do bazy danych, lub wręcz nie korzysta z gotowych, przetestowanych wyrażeń SQL, zabezpieczenie danych przed atakiem w rodzaju SQL injection będzie wymagać wdrożenia odrębnych zabezpieczeń, a także utrzymywania ich w zgodności z aplikacją wraz z jej ewolucją.

W dyskusji o jakości i bezpieczeństwie oprogramowania nie może zabraknąć wątku wdrożeniowego i utrzymaniowego. Nie ma to jak wdrożyć bezpieczną, przetestowaną w 100% aplikację w środowisku umożliwiającym dostanie się do bazy danych „z boku”, z pominięciem zabezpieczeń aplikacyjnych. Albo też w środowisku, które sieć lokalną, z powodu istnienia zabezpieczeń na obrzeżu tejże sieci, uznaje się automatycznie za bezpieczną. Bezpieczną aplikację i jej poprawnie chronione środowisko można także w sposób mało bezpieczny udostępnić zdalnie. Fantazja nie zna granic.