(Najtrudniejsze) Podstawy bezpieczeństwa aplikacji

W cyklu życia aplikacji NAJtrudniejsze są podstawy bezpieczeństwa. Chciałbym poruszyć dość poważny, często lekceważony problem w procesie powstawania i rozwoju aplikacji (SDLC). Zanim do tego dojdę to trochę o powodach dlaczego uznałem temat za warty wpisu na blogu.



Bardzo jest miło kiedy grupa zbiera się na tyle wcześnie, że mogę dobrze zaplanować mój kolejny tydzień, a jeszcze lepiej jeśli myślę o miesiącu. Tak też się stało ze zbliżającą się edycją warsztatów. Dziękuję za zaufanie i postaram się nie zawieść - następna jeszcze w tym roku.

Co takiego skłoniło mnie w temacie warsztatów do przemyśleń o SDLC? Otóż dość spore zainteresowanie nimi. Testy penetracyjne aplikacji webowych to niewątpliwie teraz temat numer jeden (przynajmniej w środowiskach, w których się obracam, a są one bardzo różne) wśród sposobów zapewnienia bezpieczeństwa aplikacji. Oczywiście pośrednio, bo same testy nie wpływają na poziom bezpieczeństwa, a jedynie go sondują. Niepodważalny jest fakt, że testy są potrzebne i nie namawiam do odchodzenia od nich.

Przez ostatnich kilka lat spotkałem się z bardzo skrajnym podejściem programistów do problemu bezpieczeństwa aplikacji. Pod pojęciem programisty rozumiem zarówno dewelopera, architekta aplikacji i sztabu ludzi, którzy są najbliżej cyklu życia aplkacji. Z jednej strony widzę programiste, który pyta w jaki sposób zaimplementować dany mechanizm bezpieczeństwa, czy narażony jest on na jakieś ataki, a z drugiej (bezczelnego), takiego który ustosunkuje się tylko do błędów wykazanych w raporcie z testu penetracyjnego, ale właściwie tylko tych ze statusem CRITICAL. Stosunek do bezpieczeństwa aplikacji obu podejść jest zdecydowanie inny. Kiedyś przeżyłem szok kiedy jeden z moich kolegów, który zawodowo tworzy aplikacje w języku klasy Enterprise zapytał mnie, czy jak poszedł do "bezpieczników" w firmie gdzie pracuje i zapytał ich o wytyczne, może jakieś źródła informacji o tym jak bezpiecznie wykonać implementację jednego z ważniejszych projektów to czy się wygłupił. Chwila konsternacji... i aby nie oceniać za szybko (jego i owych bezpieczników) mało elegancko zapytałem skąd ta obawa. Okazało się, że programista został zbyty informacją by teraz nie zawracał głowy. Bezpiecznicy zadeklarowali chęć zajęcia się tematem jak będzie trzeba przetestować aplikację przed "wystawieniem na Świat". Żeby nie wdawać się w szczegóły ;) ze swojej strony powiedziałem koledze, że szkoda, że nie pracujemy razem - bo taki programista to Skarb. Nie dość, że jest zainteresowany tematem bezpieczeństwa zanim zaczął pisać to jeszcze sam pofatygował się do tych, którzy powinni o tym wiedzieć najlepiej. Nie chcę rozmieniać się na drobne by ocenić postawę "bezpieczników", którzy tak podeszli do tematu... lepiej jak zostawię uśmieszek :-) Mam nadzieję, że na podstawie tych kilku postaw (bezczelnego programisty i nazwę to, leniwego bezpiecznika) przybliżyłem problem z jakim większość z nas się boryka.

W takim razie jak ogarnąć temat bezpieczeństwa aplikacji zanim dojdzie do testów penetracyjnych?

Pisali o tym wprost i między wierszami mądrzy ludzie, którzy zajmują się bezpieczeństwem aplikacji dłużej niż ja żyję - może trochę przesadziłem ;). Nie będę oryginaly i wymienię następujące tematy:
- standard bezpieczeństwa, którego powinni się trzymać programiści przy implementacji zarówno samej aplikacji jak i mechanizmów bezpieczeństwa, w które zostanie ona wyposażona,
- trening = szkolenia + warsztaty dla programistów, tematyka wzięto prosto ze standardu i na zachętę pokaz konsekwencji nie trzymania się standardu - pokaz w stylu 'case study' na błędach kolegów może wyostrzyć wyobraźnię i być pozytywnym bodźcem do zdrowej konkurencji pomiędzy programistami,
- modelowanie zagrożeń per aplikacja i najlepiej infrastruktura (im wcześniej [zanim powstanie pierwszy kB kodu] tym lepiej).

Dopiero gdzieś tutaj jest moment kiedy aplikacja jest tworzona (programista pisze kod). Standard oraz trening pozwala programistom przewidywać pewne zagrożenia i daje wskazówki jak minimalizować ryzyko ich występowania/wykorzystania. Modelowanie zagrożeń pozwoli programiście wspólnie z konsultantem ds. bezpieczeństwa (najlepiej aplikacji, a nie tylko firewalli...) zidentyfikować zagrożenia, ... i określić środki minimalizujące ryzyko wykorzystania ich. Jak aplikacja dojrzeje do testów bezpieczeństwa to właściwie zaczyna się temat..., ale jeszcze nie pentestów. Niespodzianka? Testy bezpieczeństwa i nie muszą, a nawet więcej, nie zawsze mają postać testów penetracyjnych. Mogą je zastąpić lub występować równolegle dość czasochłonne przeglądy kodu (code review).

To nie wszystko, a już ta krótka lista może być natchnieniem dla kilku blogów. O ile będę miał trochę (więcej) szczęścia - czasu, kolejne wpisy rozwiną tematykę podstaw bezpieczeństwa aplikacji, które przedstawiłem powyżej.