Na wstępie zacznę od pewnej dygresji… Kiedy dziesięć lat temu powstawała Strefa PMI, której miałem przyjemność być pomysłodawcą i pierwszym redaktorem naczelnym, nie przypuszczałem, że tak ważne w każdym projekcie jest coś, co niektórzy nazywają modelem operacyjnym, a ja wolę nazywać formatem działania. Jak wiemy, niektóre formaty trwają bardzo krótko i jeśli nie mają solidnych podstaw opartych na ludziach z pasją, szybko się dezaktualizują i odchodzą w zapomnienie. Strefa rozwija się z roku na rok i przez dekadę udowodniła, że format jej działania był strzałem w dziesiątkę – zatem życzę „100 lat”.


Ad rem… W tym artykule opisuję strategiczne elementy istotne w implementacji cyklu rozwoju bezpiecznego oprogramowania (ang. Secure Software Development Lifecycle, dalej – SSDLC) w dużej organizacji.

Sposób realizacji dużego projektu ma ogromne znaczenie dla późniejszego utrzymania produktów, jakie dostarcza. Im większe przedsięwzięcie, tym bardziej istotna staje się precyzja i dostosowanie metodyczne. Ktoś mógłby powiedzieć: „to trochę frazes”. Lecz podkreślam to, bo należę do osób, które uważają, że po pierwsze – kierownik projektu musi rozumieć merytorykę prowadzonego przez siebie projektu (są tacy, którzy to kontestują), a po drugie – im bardziej projekt jest skomplikowany, tym bardziej powinien podążać ścieżką dostosowania metodyki do specyfiki tego konkretnego wdrożenia.

Podstawą jest zrozumienie umiejscowienia zmian w obecnym procesowym ekosystemie organizacji. Błędy popełniane w fazie planowania, kiedy powstaje strategia implementacji rozwiązania (którego składową jest kilkanaście systemów informatycznych oraz dochodzi do rekonstrukcji kilku już działających, dość skomplikowanych i krytycznych, procesów organizacyjnych), zawsze wpływają negatywnie na cały proces zmian. W wyniku tego może dojść do całkowitego odrzucenia rozwiązania.

Strategia – tzw. shift left

Zacznijmy od głównego celu tego rodzaju projektu – shift left, czyli im szybciej, tym lepiej – dla odnajdywania i usuwania podatności bezpieczeństwa. Trzeba pamiętać, że w dużych organizacjach realizowanych jest wiele jednoczesnych procesów zapewniających bezpieczeństwo. Procesy te wzajemnie nachodzą na siebie i czasem przenikają tak, żeby zapewnić dla całości monolityczną barierę, jakiej nie będą mogli przejść cyberprzestępcy. Poznajmy kilka z nich.

Proces pierwszy – testy ethical hacking

Wiele organizacji realizuje postulat zapewnienia bezpieczeństwa oprogramowania przez bardzo dogłębne testy penetracyjne, realizowane na wydawanym oprogramowaniu. Są to prace wykonywane przez profesjonalnych ethical hackerów, którzy na wszelkie znane sposoby weryfikują bezpieczeństwo aplikacji – próbując „włamań” w bardzo podobny sposób, jak robią to cyberprzestępcy. Efektem ich pracy jest raport dotyczący zidentyfikowanych luk bezpieczeństwa, zawierający wskazania dla autorów oprogramowania (dalej – Dev) i zespołów administratorskich (dalej – Ops) w tym zakresie. To podejście ma swoje zalety, ale jedną z jego wad jest to, że o błędach tych dowiadujemy się w zasadzie w momencie, w którym aplikacja jest gotowa do udostępnienia użytkownikom. Zatem w momencie wychwycenia błędów trzeba bardzo często przebudować systemy tuż przed ich terminem oddania do użytkowania. 

Proces drugi – skanowanie i usuwanie podatności

Żeby ograniczyć opisywany wyżej problem, stosowany jest proces skanowania tzw. podatności i wyszukiwania ich w aplikacjach znajdujących się na środowiskach testowych, ale też produkcyjnych. Codziennie znajdowane są nowe podatności, a aplikacja, która wczoraj uważana była za bezpieczną, następnego dnia może mieć już luki tzw. zero day, które należy natychmiast usuwać. Skanowanie przynosi skategoryzowane informacje o występujących podatnościach. Dość popularnym i powszechnie udostępnianym, lecz nie jedynym, zbiorem identyfikatorów podatności i ich nazewnictwa jest CVE (ang. Common Vulnerabilities and Exposures), wspierany przez organizację MITRE. Na podstawie kategoryzacji i wiedzy dostarczanej przez identyfikatory podatności, w opisywanym procesie powstają raporty dla zespołów Dev i Ops. Raporty te pozwalają zrozumieć, z jaką luką mamy do czynienia i dokonać odpowiedniej korekty. Czasem może się też okazać, że konkretny przypadek jest fałszywie pozytywny (ang. false positive), a co za tym idzie, nie ma sensu się nim zajmować, bo na przykład w konkretnym ekosystemie informatycznym jego usunięcie nie jest potrzebne. Proces ten ma wiele zalet dzięki swojej prostocie i powtarzalności, ale jednak realizowany jest na już istniejących aplikacjach albo aplikacjach w zaawansowanym stadium testowania.

Proces trzeci – czyli nasz crème de la crème – SSDLC

Koncentruje się, można powiedzieć, nie na leczeniu choroby, ale jej zapobieganiu. Składa się z kilku faz. Żeby go zrozumieć, trzeba zrobić jeszcze jedną dygresję, tym razem dotyczącą rozwoju współczesnego oprogramowania. Jeszcze kilkanaście lat temu firma wydająca oprogramowanie robiła podczas premiery swojego flagowego produktu wielkie show z gwiazdami filmu i muzyki (bankiet trwał do rana), a istotna poprawka bezpieczeństwa do tego systemu ukazywała się po kilkunastu tygodniach. Obecnie cykl wydawania oprogramowania liczy się w dniach, jeśli nie w godzinach. Pojęcia takie jak continuous integration i continuous delivery nie są już tylko i wyłącznie ciekawą ideą, ale codziennością. Dość popularna stała się współpraca zespołów programistycznych z zespołami administratorskimi, tworzącymi w sposób zwinny aplikacje w modelu tzw. DevOps. I tutaj pojawia się nasz element układanki – odpowiedzialny za bezpieczeństwo. Żeby tworzyć nowe aplikacje spełniające wszystkie wymogi UX i potrzeby biznesu i jednocześnie być odpornym na coraz bardziej profesjonalizujący się świat cyberprzestępców, konieczne jest dodanie do powyższego zestawu części security i działanie we wspólnym modelu DevSecOps. Proces SSDLC jest tu narzędziem i metodycznym dopełnieniem (choć nie jedynym) układanki.

Pięć stadiów cyklu SSDLC

Modelowanie zagrożeń (ang. Threat Modeling) – wielu błędów bezpieczeństwa można uniknąć na etapie projektu technicznego i weryfikacji, czy nie brakuje w nim ujęcia komponentów, które przez swoje zastosowanie spowodują, że niektóre techniki ataku cyberprzestępców będą po prostu z założenia niemożliwe. Zatem, zanim rozpocznie się pisać kod, może lepiej trzy razy się zastanowić, jak to zrobić, żeby od samego początku system był „bulletproof”.

Analiza kompozycji oprogramowania (ang. SCA – Software Composition Analysis) – wraz ze wzrostem wykorzystania oprogramowania typu open source software (OSS) istnieje coraz większa potrzeba śledzenia komponentów dostarczanych w ten sposób, bo czasem to, co jest ogólnodostępne, może być też polem eksploatacji cyberprzestępców. SCA pozwala na automatyzację wglądu w wykorzystywane oprogramowanie tego typu i, co też ważne, dostarcza wiedzę o ich licencjonowaniu.

Statyczne testy bezpieczeństwa aplikacji (ang. SAST – Static Application Security Testing) – to rozwiązanie, które skanuje kody źródłowe aplikacji. Jako narzędzie testowe typu white-box identyfikuje pierwotną przyczynę podatności i pomaga naprawić podstawowe błędy bezpieczeństwa. Rozwiązania SAST analizują aplikację „od środka” i nie wymagają uruchomionego systemu do przeprowadzenia skanowania.

Dynamiczne testowanie bezpieczeństwa aplikacji (ang. DAST – Dynamic Application Security Testing) – jest to analiza aplikacji „w użyciu” w celu znalezienia podatności poprzez symulowane ataki. Ten rodzaj podejścia ocenia aplikację poprzez jej atakowanie w taki sposób, jak zrobiłby to złośliwy użytkownik lub cyberprzestępca.

Warstwa integracyjna – system zarządzania podatnościami (ang. VMS – Vulnerability Management System) – zintegrowane z innymi procesami rozwiązanie do zarządzania cyklem życia podatności w organizacji. Pozwala na prawidłową komunikację między zespołami Dev, Sec i Ops w kontekście zarządzania podatnościami ujawnianymi na różnych etapach opisywanych wyżej weryfikacji. Ułatwia zarządzanie odstępstwami i wspominanymi wcześniej przypadkami false positive.

To co opisałem powyżej, jest pewnym pobieżnym rysem, jaki każdy kierownik projektu powinien znać i brać pod uwagę na początku realizacji projektu implementacji SSDLC. To początek strategii. Jest dość dużo źródeł opisujących te zagadnienia, a więc określenie wstępnej strategii projektu nie powinno nastręczyć dużo problemów. Trudniej wygląda sytuacja, jeśli schodzi się na poziom taktyczny, bo każda organizacja jest inna. Trzeba wówczas wziąć pod uwagę skalę zmian biznesowych oraz, co za tym idzie, developerskich w organizacji. Następnie należy uwzględnić liczbę różnych technologii obsługiwanych przez proces wytwórczy, liczbę zespołów i ich kulturę pracy, wiedzę i chęć jej poszerzania o aspekty bezpieczeństwa wśród interesariuszy projektu, tendencję do silosowania się poszczególnych jednostek, złożoność procesów wspomagających, takich jak tworzenie architektury systemów, cykli i skomplikowanie procesu zarządzania wydaniami. Dużo tego, ale jednak trzeba to wszystko połączyć ze strategią, bo jak powiedział Sun Tzu – „Strategia bez taktyki jest najwolniejszą drogą do zwycięstwa. Taktyka pozbawiona strategii jest zgiełkiem poprzedzającym klęskę”.

Jednakże taktyka dla tego rodzaju projektu to już nie temat na krótki artykuł, ale na całkiem grubą książkę.