Co programiści powinni wiedzieć na temat bezpieczeństwa? Wywiad z Pawłem Malitą

Wiele osób twierdzi, że podczas nauki programowania nie uwzględnia się tematu bezpieczeństwa w obszarze rozwijanych aplikacji. Poprosiliśmy Pawła Malitę – eksperta w dziedzinie cyberbezpieczeństwa – o opinię jak powinien wyglądać proces wytwarzania bezpiecznego oprogramowania.

Barbara Kowalewska, IT-Leaders: Na początek, proszę przybliż naszym czytelnikom czym się na co dzień zajmujesz?

Na co dzień pracuję w G2A.COM, największej na świecie platformie sprzedażowej specjalizującej się w grach i innych produktach cyfrowych, jako architekt bezpieczeństwa. Pomagam twórcom aplikacji modelować zagrożenia i doradzam przy wyborze najkorzystniejszych rozwiązań pozwalających minimalizować ryzyko. Czasami, gdy grupa odbiorców jest większa, doradztwo zamienia się spore szkolenie dla zespołu: developerów, architektów, testerów.

Nadzoruję też bezpieczeństwo informacji oraz program zgodności z standardem PCI-DSS w firmie z branży fintech, a w ramach własnej działalności pod marką Get-Secure.net doradzam w zakresie szeroko pojętego cyberbezpieczeństwa. W wolnych chwilach działam jako badacz bezpieczeństwa, czy jak kto woli – white hacker, w programach bug bounty, wyszukując podatności w produktach innych firm.

Posiadasz wieloletnie doświadczenie w tematach dotyczących cyberbezpieczeństwa, czy wg Ciebie przeciętna firma zajmująca się rozwojem oprogramowania, poświęca wystarczająco dużo uwagi zagadnieniom bezpieczeństwa wytwarzanych produktów?

Ciężko jest odpowiedzieć jednoznacznie na to pytanie.

To, co widzę wyraźnie, to wzrost zainteresowania bezpieczeństwem wytwarzanego oprogramowania, który przejawia się w dużym zainteresowaniu szkoleniami, narzędziami do wspomagania tworzenia bezpiecznego oprogramowania, czy dużą ilością zapytań o testy penetracyjne.

Możliwe, że jakiś swój udział w tym miały szeroko nagłaśnianie przez media przypadki wycieków danych oraz ustawodawstwo kładące nacisk na bezpieczeństwo, takie jak chociażby RODO.

Moim zdaniem, w podnoszeniu poziomu bezpieczeństwa pomaga też zmiana sposobu wytwarzania oprogramowania.

Co takiego się zmieniło w sposobie wytwrzania oprogramowania, co nadało większy priorytet bezpieczeństwu?

W tradycyjnym podejściu, na przykład typu waterfall, bezpieczeństwo było weryfikowane na samym końcu cyklu wytwarzania oprogramowania. W takim przypadku, po wykryciu poważnych błędów produkt powinien wrócić do poprawy a nieraz do przeprojektowania architektury, co było niesamowicie kosztowne i znacznie wydłużało czas dostarczenia produktu na rynek. Właściciele biznesowi stawali przed dylematem i niestety bardzo często bezpieczeństwo przegrywało walkę o budżet.

Dziś większą wartością dla biznesu jest szybki czas dostarczenia produktu oraz możliwość reakcji na częste zmiany wymagań.

W procesie wytwarzania oprogramowania króluje filozofia DevOps, zwinne wytwarzanie oprogramowania, wykorzystanie automatyzacji i systemów Continous Intergation/Continous Delivery. Stosunkowo małe zmiany, także usprawnienia bezpieczeństwa, można wprowadzać i testować je często, oraz automatycznie a przez to tanio.

Działy bezpieczeństwa przestają być takim policjantem z checklistą, które stają na przeszkodzie biznesowi i twórcom aplikacji, ale są bliżej procesu wytwarzania oprogramowania.

Bezpieczeństwo aplikacji staje się odpowiedzialnością całego zespołu i przekłada się to na coraz bezpieczniejsze produkty, jest więc moim zdaniem zdecydowanie lepiej niż kiedyś.

Jakich w takim razie wskazówek jako ekspert w dziedzinie bezpieczeństwa mógłbyś udzielić programistom zajmującym się rozwojem aplikacji webowych?

Przede wszystkim zalecam wykorzystanie wiedzy i doświadczenia innych.

Tworząc oprogramowanie najlepiej wykorzystywać gotowe, znane i przetestowane (także pod kątem bezpieczeństwa) frameworki i biblioteki. Absolutny grzech numer jeden to samodzielne tworzenie własnych, krytycznych funkcji bezpieczeństwa takich jak algorytmy szyfrowania.

Kolejna wskazówka to automatyzacja i narzędzia do mierzenia bezpieczeństwa. Takim dobrym przykładem mogą być wtyczki do środowiska programistycznego (IDE) wykonujące analizę statyczną kodu. Jeśli istnieje możliwość wpięcia automatycznych testów bezpieczeństwa w narzędzia CI/CD to warto z nich korzystać.

Aby unikać najczęściej popełnianych błędów sugeruję sięgnąć po standardy mierzenia bezpeczeństwa aplikacji na przykład OWASP Application Security Verification Standard. Jest to o tyle wartościowe opracowanie, że oprócz metod na zmierzenie bezpieczeństwa aplikacji daje porady, jak można zapobiegać błędom.

Absolutną podstawą powinno być zapoznanie się z listą najczęściej występujących błędów w aplikacjach webowych (OWASP Top 10) i sposobami ich unikania.

I na koniec coś, co zdaje się wszystkim osobom z działów IT przychodzić najtrudniej – prosić o pomoc bardziej doświadczonych kolegów. Jeszcze nie spotkałem senior developera, czy nawet „bezpiecznika”, który odmówiłby podzielenia się wiedzą, a każdy z nas ciągle uczy się czegoś nowego.

Jakie zauważasz najczęstsze słabe punkty w oprogramowaniu, wynikające z zaniedbań po stronie programistów?

Najczęstszy błąd jaki wykrywałem w oprogramowaniu to niewystarczająca walidacja danych wejściowych. Co ciekawe, jest to błąd, którego łatwo uniknąć stosując frameworki. Zdarzało się, że dane, które na pierwszy rzut oka nie są danymi wejściowymi, na przykład nagłówki HTTP takie jak Cookies, czy UserAgent są pomijane przy wdrażaniu walidacji.

Tworząc bezpieczne oprogramowanie developer powinien wejść w buty nieposłusznego użytkownika, który nie będzie podążał za instrukcją i grzecznie używał aplikację, tylko wykona z nią najbardziej szalone rzeczy. Tak jak w tym dowcipie: wchodzi tester do baru i zamawia -9999 piw…

Pozostałe najczęściej pojawiające się błędy nie dotyczą samych programistów. Są to nieprawidłowe konfiguracje usług, oraz brak zaprojektowania funkcjonalności dostarczających bezpieczeństwa danych, takich jak na przykład uwierzytelnianie wieloskładnikowe.

Czy stanowisko security software developer-a powinno być standardem w firmie zajmującej się komercyjnym rozwojem oprogramowania?

Wydaje mi się, że zmieniający się proces tworzenia oprogramowania wyeliminuje potrzebę posiadania takiego dedykowanego stanowiska poprzez automatyzację testów i szerzenie wiedzy. W zespołach sprawdzanie kodu pod kątem jakości a więc i bezpieczeństwa, będą wykonywać automaty (analiza statyczna) oraz senior developerzy. Odrzucając pull request, osoba sprawdzająca kod wytłumaczy powód odrzucenia, w ten sposób każdy programista będzie się uczył i tworzył coraz bardziej bezpieczny kod.

Błędy, które wrócą z testów dynamicznych, będą w tym samym zespole poprawiane co także spowoduje wzrost kompetencji w dziedzinie bezpiecznego tworzenia oprogramowania.

Jeśli tylko zespół będzie nagradzany za coraz lepszą jakość produktu, a nie tylko będzie myślał jak oszukać automaty, to w drodze naturalnego rozwoju każdy programista będzie security software developerem.

Jak w takim razie rozwinąć w zespole programistów kompetencje z zakresu bezpieczeństwa?

Na początek oczywiście potrzebny jest ten pierwszy senior, mentor, który będzie wiedzę na temat bezpiecznego programowania posiadał – jego trzeba niestety najpierw zrekrutować, lub przeszkolić zewnętrznie.

Nie nazywałbym go jednak security software developerem, żeby nie stwarzać wrażenia, że tworzenie bezpiecznego kodu to wyłącznie jego zadanie. Może się powtórzę, moim zdaniem bezpieczeństwo to odpowiedzialność każdego członka zespołu, tak jak na przykład bezpieczeństwo na drodze to odpowiedzialność każdego uczestnika ruchu.

Osobne zagadnienie to stworzenie wymagań bezpieczeństwa dla aplikacji oraz bezpiecznej architektury – to są zadania wykraczające poza zespół deweloperski i jest to temat na duży artykuł.

Wiadomo, że każda firma stara się zachować swoją metodykę pracy na tyle tajną, na ile jest to możliwe. Gdybyś miał jednak wskazać – praktyki której z firm w zakresie dbałości o bezpieczeństwo wytwarzanych aplikacji poleciłbyś jako wzór do naśladowania?

Odpowiem politycznie… Każda firma, która mierzy i testuje bezpieczeństwo swoich aplikacji i, co ważne, poprawia wykryte błędy stosownie do ryzyka jakie niosą, jest godna naśladowania.

Jeśli twórcy oprogramowania są nagradzani nie tylko za terminy ale także za jakość, w tym bezpieczeństwo, to jest to właściwy, moim zdaniem, sposób na dostarczanie produktów.

Czy możesz polecić jakieś wartościowe źródła do nauki zagadnień dotyczących cyberbezpieczeństwa dla programistów?

Obecnie najlepsze źródło wiedzy, według mnie, to ściągawki (Cheat Sheets) od OWASP. Pozycji książkowych o bezpiecznym programowaniu nie ma zbyt wiele, znacznie więcej jest opracowań na temat testowania bezpieczeństwa.

Ciekawie zapowiada się jeden tytuł: „Bezpieczeństwo aplikacji webowych” przygotowywany przez autorów z firmy Securitum.

Zachęcam też do uczestnictwa w szkoleniach z zakresu bezpieczeństwa aplikacji WWW.

Na koniec, jak według Ciebie powinien wyglądać idealny model rozwoju oprogramowania?

Taki model już istnieje i co najważniejsze, jest stosowany. To Agile SSDLC, czyli Secure Software Development Lifecycle i o jego niektórych elementach już wspominałem.

Bezpieczeństwo jest udziałem całego zespołu i jest włączone od samego początku cyklu wytwarzania aplikacji.

Każda zmiana jest testowana pod kątem bezpieczeństwa: analiza statyczna, badanie znanych podatności w zależnościach, testy dynamiczne aplikacji, na równi z testami funkcjonalnymi. Testy wykonywane są automatycznie. Manualnie wykonuje się testy działania logiki biznesowej. System CI/CD nie pozwala wdrożyć na produkcję zmiany, jeśli nie przeszła któregokolwiek testu. Po przejściu testów wewnętrznych, zmiany są wdrażane na środowisku typu sandbox dostępnym publicznie oraz równolegle na produkcję. Na środowisku sandbox społeczność white hackerów testuje podatności i zgłasza je, za co dostaje wynagrodzenie stosownie do wartości zgłoszenia (success fee). Zespół wrzuca zgłoszone błędy na szybką ścieżkę (fast track), poza zwykłymi zaplanowanymi sprintami. Po usunięciu błędów na produkcji hacker może opisać swoje odkrycie – zgodnie z polityką responsible disclosure. Alternatywnie do testów penetracyjnych przeprowadzanych przez społeczność, na zasadzie wynagrodzenia za sukces, można wykonywać testy penetracyjne na zamówienie lub utrzymywać wewnętrzny zespół pentesterów. Jest to jednak dość drogie rozwiązanie, raczej przeznaczone dla firm, które podlegają takiemu obowiązkowi, na przykład z tytułu przetwarzania danych kart kredytowych. Na koniec klient cieszy się z w miarę bezpiecznego produktu, firma zyskuje renomę i zaufanie, także przez przyznanie się do błędów.