Do największych "wrogów" bezpieczeństwa należą napięte harmonogramy projektów. Z braku czasu testy bezpieczeństwa wykonywane są "za pięć dwunasta" - po testach funkcjonalnych, tuż przed produkcyjnym uruchomieniem aplikacji. Do wyjątków nie należą sytuacje, gdy ze względu na zbliżający się termin uruchomienia aplikacji, rezygnuje się nawet z końcowej oceny bezpieczeństwa lub wykonuje się taką ocenę już po uruchomieniu aplikacji, podejmując ryzyko naruszenia bezpieczeństwa w pierwszych dniach rozruchu systemu.

Bezpieczeństwo aplikacji często nie jest nawet wspominane w kontraktach. A szkoda, bo wykrycie błędów w zabezpieczeniach oznaczałoby nienależyte wywiązanie się dostawcy ze zobowiązań i skłoniłoby do podjęcia choćby podstawowych kroków zmierzających do eliminacji błędów. Gdy w umowie nie ma mowy o bezpieczeństwie, dostawca nie ma motywacji, by o nie dbać bez dodatkowej zapłaty. Klient często łudzi się, że podpisując kontrakt na wykonanie systemu, zgodnie z regułami sztuki, godzi się na dostarczenie produktu pod wieloma względami bezpiecznego. Zwłaszcza, gdy dostawca szczyci się certyfikatem ISO 9000.

Ta nadzieja bywa jednak często bardzo zwodnicza. Znając swój biznes, nawet poważny dostawca, zwłaszcza w warunkach przetargu publicznego, nie wysunie kwestii bezpieczeństwa jako oddzielnej sprawy. Będzie to bowiem zrozumiane jako oddzielna pozycja na fakturze i sprawi, że przegra przetarg z firmami, które obiecują gruszki na wierzbie. Dostawca zakłada, że jeśli nie zajdzie nic nadspodziewanego, braku zabezpieczeń klient nie będzie mu raczej w stanie udowodnić. Gra pozorów trwa więc w najlepsze do czasu, gdy okazuje się, że "dziurawa" aplikacja posłużyła jako furtka do zdobycia poufnych informacji.

Jedynym sposobem na osiągnięcie bezpiecznej aplikacji bez poświęcania innych parametrów projektu jest uczynienie z bezpieczeństwa jednego z wymagań projektu i kontrolowanie go na bieżąco w trakcie trwania projektu. Nie jest to bynajmniej proces skomplikowany. W większości przypadków wystarczy krótkie szkolenie "uświadamiające" dla programistów, przyjęcie zestawu dobrych praktyk programistycznych i ewentualne uwzględnienie w projekcie konsultanta dbającego o bezpieczeństwo tworzonej aplikacji lub posłużenie się oprogramowaniem wykrywającym typowe błędy w kodzie. Te nakłady nie są duże - w odróżnieniu od nakładów koniecznych do poniesienia w przypadku wykrycia poważnych luk w zabezpieczeniach na etapie testów końcowych.

Wierzchołek góry

Błędy popełnione na etapie projektowania oraz kodowania aplikacji pisanej na zamówienie są bardzo trudne do naprawienia po uruchomieniu systemu. Bezpieczeństwo takiego systemu nie jest ważniejsze niż bezpieczeństwo innych aplikacji, nie jest jednak mniej ważne. Wiedząc to, klienci powinni zwracać baczniejszą uwagę na to, jak formułowane są wymagania i w jaki sposób weryfikowane są efekty prac na kolejnych etapach projektu. Skutki zaniedbań w tym względzie mogą być trudne do oszacowania, co oczywiście nie znaczy, że można nie brać ich pod uwagę. Problemy zaznaczone w tym artykule postaram się rozwinąć w kolejnych publikacjach. Niniejszy artykuł jest zwiastunem kilku bardziej szczegółowych opracowań, które ukażą się w przyszłych wydaniach Computerworld.

Wojciech Dworakowski jest ekspertem ds. bezpieczeństwa IT w firmir SecuRing. Zajmuje się m.in. testowaniem bezpieczeństwa aplikacji.