Mieliśmy 2 analizatory kodu, 4 narzędzia do testowania dynamicznego, własne wynalazki i 250 skryptów. Nie to, żeby to wszystko było potrzebne w obecnym procesie, ale skoro zacząłem wdrażać DevSecOps, to trzeba to zrobić do końca.
. Autorzy postaci: Justin Roiland i Dan Harmon.
Czym jest SecDevOps? A DevSecOps? Jakie są różnice? Bezpieczeństwo aplikacji - o czym to? Dlaczego klasyczne podejście już nie działa? Na wszystkie te pytania zna odpowiedź Jurij Szabalin z Swordfish Security. Jurij szczegółowo na wszystko odpowie i omówi problemy związane z przejściem od klasycznego modelu bezpieczeństwa aplikacji do procesu DevSecOps: jak prawidłowo podejść do integracji procesu bezpiecznego rozwoju w proces DevOps i niczego przy tym nie zepsuć, jak przejść przez główne etapy testowania na bezpieczeństwo, jakie narzędzia można stosować, czym się różnią i jak je prawidłowo skonfigurować, aby uniknąć pułapek.
O prelegencie: Jurij Szabalin - Główny architekt bezpieczeństwa w firmie Swordfish Security. Odpowiada za wdrożenie SSDL, za ogólną integrację narzędzi analizy aplikacji w jedną ekosystemę rozwoju i testowania. 7 lat doświadczenia w bezpieczeństwie informacji. Pracował w Alfa-Bank, Sberbank i w Positive Technologies, która rozwija oprogramowanie i dostarcza usługi. Prelegent międzynarodowych konferencji ZerONights, PHDays, RISSPA, OWASP.
Bezpieczeństwo aplikacji: o czym to?
Bezpieczeństwo aplikacji to dział bezpieczeństwa, który odpowiada za bezpieczeństwo aplikacji. To nie odnosi się do infrastruktury ani do bezpieczeństwa sieci, a konkretnie do tego, co piszemy i nad czym pracują programiści - to niedociągnięcia i luki samej aplikacji.
Kierunek — Cykl życia rozwoju bezpieczeństwa został opracowany przez firmę Microsoft. Na schemacie - kanoniczny model SDLC, którego głównym celem jest uczestnictwo bezpieczeństwa na każdym etapie rozwoju, od wymagań po wydanie i wyjście na produkcję. W Microsoft uznano, że w produkcie jest zbyt wiele błędów, ich liczba rośnie i trzeba coś z tym zrobić, i zaproponowano to podejście, które stało się kanoniczne.
Bezpieczeństwo aplikacji i SSDL nie mają na celu wykrywania luk, jak się powszechnie sądzi, ale zapobieganie ich powstawaniu. Z biegiem czasu kanoniczne podejście Microsoftu zostało ulepszone, rozwinięte, wprowadzono w nim głębsze, bardziej szczegółowe zanurzenie.
Kanoniczny SDLC jest szczegółowo opisany w różnych metodologiach - OpenSAMM, BSIMM, OWASP. Metodologie różnią się, ale w zasadzie są podobne.
Model Dojrzewania Bezpieczeństwa
Najbardziej przemawia do mnie BSIMM — . Podstawą metodologii jest podział procesu bezpieczeństwa aplikacji na 4 domeny: Governance, Intelligence, SSDL Touchpoints oraz Deployment. W każdej domenie znajduje się 12 praktyk, które są przedstawione w formie 112 aktywności.
Każda z 112 aktywności ma 3 poziomy dojrzałości: podstawowy, środkowy i zaawansowany. Wszystkie 12 praktyk można studiować w sekcjach, wybierając ważne dla siebie elementy, zrozumieć, jak je wdrażać i stopniowo dodawać elementy, takie jak statyczna i dynamiczna analiza kodu lub przegląd kodu. Tworzy się plan i spokojnie pracuje w ramach wdrażania wybranych aktywności.
Dlaczego DevSecOps
DevOps to ogólny, duży proces, w którym należy dbać o bezpieczeństwo.
Początkowo zakładał sprawdzanie bezpieczeństwa. W praktyce liczba zespołów odpowiedzialnych za bezpieczeństwo była znacznie mniejsza niż obecnie, a one uczestniczyły nie jako uczestnicy procesu, lecz jako organ kontrolny i nadzorczy, który stawia wymagania i sprawdza jakość produktu na końcu wydania. To klasyczne podejście, w którym zespoły bezpieczeństwa były oddzielone od rozwoju i nie brały udziału w procesie.
Głównym problemem jest to, że IIB są oddzielone od rozwoju. Zwykle to jakiś kontur IIB i w nim 2-3 dużych i kosztownych narzędzi. Co pół roku przybywa kod źródłowy lub aplikacja, która musi być sprawdzona, a raz w roku przeprowadzane są . To wszystko prowadzi do wydłużenia terminów wprowadzenia na rynek, a dla dewelopera pojawia się ogromna ilość podatności z automatycznych narzędzi. Wszystko to jest niemożliwe do rozłożenia i naprawienia, ponieważ jeszcze przez ostatnie pół roku nie przeanalizowano wyników, a tutaj nadchodzi nowa partia.
W trakcie pracy naszej firmy widzimy, że bezpieczeństwo w różnych obszarach i branżach rozumie, że nadszedł czas, aby nadążyć i współpracować z rozwojem w jednej płaszczyźnie - w . Paradigma DevSecOps doskonale wpisuje się w metodologię zwinnego podejścia, wprowadzania, wsparcia oraz udziału w każdym wydaniu i iteracji.
Przejście do DevSecOps
Najważniejsze słowo w cyklu życia bezpieczeństwa aplikacji to "proces"Musisz to zrozumieć, zanim pomyślisz o zakupie narzędzi.
Samo włączenie narzędzi w proces DevOps nie wystarczy – ważna jest interakcja i zrozumienie pomiędzy uczestnikami procesu.
Bardziej liczą się ludzie, a nie narzędzia.
Często planowanie procesu bezpiecznego rozwoju zaczyna się od wyboru i zakupu narzędzia, a kończy próbami zintegrowania narzędzia w obecnym procesie, które pozostają jedynie próbami. To prowadzi do smutnych konsekwencji, ponieważ każde narzędzie ma swoje cechy i ograniczenia.
Często zdarza się, że dział bezpieczeństwa wybiera dobre, drogie narzędzie z szerokimi możliwościami i przychodzi do programistów, aby wkomponować je w proces. Ale nie da się – proces jest zbudowany w ten sposób, że ograniczenia już zakupionego narzędzia nie pasują do obecnej paradygmy.
Najpierw opisz, jaki wynik chcesz osiągnąć i jak ma wyglądać proces. To pomoże zrozumieć role narzędzia i bezpieczeństwa w procesie.
Zacznij od tego, co już jest używane.
Zanim kupisz drogie narzędzia, sprawdź, co już masz. W każdej firmie istnieją wymagania dotyczące bezpieczeństwa, które są stawiane przed rozwojem, są kontrole, testy penetracyjne – dlaczego nie przekształcić tego wszystkiego w zrozumiały i wygodny dla wszystkich format?
Zwykle wymagania to papierowy dokument, który leży na półce. Był przypadek, kiedy przyjeżdżaliśmy do firmy, aby obejrzeć procesy i prosiliśmy o pokazanie wymagań dotyczących bezpieczeństwa oprogramowania. Specjalista, który się tym zajmował, długo szukał:
– Gdzieś teraz w notatkach był ślad, gdzie leży ten dokument.
W rezultacie otrzymaliśmy dokument po tygodniu.
Dla wymagań, kontroli i innych utwórz stronę, na przykład na Confluence – to wygodne dla wszystkich.
Prościej jest przekształcić to, co już istnieje, i wykorzystać jako punkt wyjścia.
Używaj Security Champions.
Zwykle w średniej firmie na 100-200 programistów pracuje jeden specjalista ds. bezpieczeństwa, który pełni kilka funkcji i fizycznie nie jest w stanie wszystkiego sprawdzić. Nawet jeżeli stara się z całych sił – nie jest w stanie samodzielnie sprawdzić całego kodu, który generuje rozwój. Dla takich przypadków opracowano koncepcję – .
Security Champions to osoba w zespole deweloperskim, która jest zainteresowana bezpieczeństwem twojego produktu.
Security Champion to punkt kontaktowy w zespole deweloperskim oraz ewangelista bezpieczeństwa w jednej osobie.
Zwykle, gdy do zespołu deweloperskiego przychodzi specjalista ds. bezpieczeństwa i wskazuje na błąd w kodzie, otrzymuje zdziwioną odpowiedź:
— A kim ty jesteś? Widzę cię po raz pierwszy. U mnie wszystko dobrze – mój starszy kolega podczas przeglądu kodu dał mi «apply», idziemy dalej!
To typowa sytuacja, ponieważ do starszych lub po prostu kolegów z zespołu, z którymi deweloper często współpracuje i przeprowadza przeglądy kodu, jest znacznie większe zaufanie. Jeśli zamiast specjalisty ds. bezpieczeństwa na błąd i konsekwencje wskaże Security Champion, jego słowo będzie miało większą moc.
Deweloperzy lepiej znają swój kod niż jakikolwiek specjalista ds. bezpieczeństwa. Osobie, która ma w narzędziu analizy statycznej co najmniej 5 projektów, zazwyczaj trudno jest zapamiętać wszystkie szczegóły. Security Champions znają swój produkt: co z czym współdziała i na co zwracać uwagę w pierwszej kolejności – są efektywniejsi.
Zastanów się nad wprowadzeniem Security Champions i zwiększeniem wpływu zespołu bezpieczeństwa. Dla samego mistrza jest to również korzystne: rozwój zawodowy w nowym obszarze, poszerzenie horyzontów technicznych, rozwój umiejętności technicznych, zarządzających i przywódczych, zwiększenie wartości rynkowej. To pewien element inżynierii społecznej, twoje «oczy» w zespole deweloperskim.
Etapy testowania
mówi, że 20% wysiłków daje 80% rezultatu. Te 20% to praktyki analizy aplikacji, które można i należy automatyzować. Przykłady takich aktywności to analiza statyczna – SAST, analiza dynamiczna – DAST, i kontrola Open Source. Opowiem więcej o aktywnościach, a także o narzędziach, z jakimi cechami zwykle się spotykamy przy ich wdrażaniu w proces oraz jak robić to poprawnie.
Główne problemy narzędzi
Wskaźę istotne problemy, które dotyczą wszystkich narzędzi i wymagają uwagi. Zajmę się nimi szczegółowo, aby nie powtarzać się dalej.
Długi czas analizy. Jeśli od commit do wydania na produkcję zajmuje 30 minut na wszystkie testy i budowę, to kontrole z zakresu bezpieczeństwa informacji zajmą całą dobę. Nikt nie będzie spowalniał procesu. Weźcie pod uwagę tę cechę i wyciągnijcie wnioski.
Wysoki poziom False Negative lub False Positive. Wszystkie produkty są różne, wszystkie wykorzystują różne frameworki i mają swój własny styl pisania kodu. Na różnych bazach kodu i technologiach narzędzia mogą pokazywać różny poziom False Negative i False Positive. Dlatego zwróćcie uwagę na to, co dokładnie w waszej firmie i dla waszych aplikacji będzie pokazywać dobry i wiarygodny wynik.
Brak integracji z istniejącymi narzędziami. Patrzcie na narzędzia z punktu widzenia integracji, z tym, co już używacie. Na przykład, jeśli macie Jenkins lub TeamCity - sprawdźcie integrację narzędzi z tym oprogramowaniem, a nie z GitLab CI, którego nie używacie.
Brak lub nadmierna złożoność dostosowywania. Jeśli narzędzie nie ma API, to po co jest potrzebne? Wszystko, co można zrobić w interfejsie, powinno być dostępne przez API. W idealnym przypadku narzędzie powinno mieć możliwość dostosowywania kontroli.
Brak mapy rozwoju produktu. Rozwój nie stoi w miejscu, zawsze korzystamy z nowych frameworków i funkcji, przepisujemy stary kod na nowe języki. Chcemy być pewni, że narzędzie, które kupimy, będzie wspierać nowe frameworki i technologie. Dlatego ważne jest, aby wiedzieć, że produkt ma realną i odpowiednią rozwoju.
Cechy procesu
Oprócz cech narzędzi, bierzcie pod uwagę również cechy procesu tworzenia. Na przykład, przeszkadzanie w tworzeniu to typowy błąd. Zobaczmy, jakie jeszcze cechy należy uwzględnić i na co zwrócić uwagę zespołowi bezpieczeństwa.
Aby nie opóźniać terminów tworzenia i wydania, stwórzcie różne zasady i różne show stoppers — kryteria wstrzymania procesu budowy w przypadku wystąpienia luk — dla różnych środowisk.Na przykład rozumiemy, że obecna gałąź idzie na środowisko deweloperskie lub UAT, więc nie zatrzymujemy się i nie mówimy:
— Macie tutaj luki, nie przejdziecie dalej!
Na tym etapie ważne jest, aby powiedzieć deweloperom, że są problemy bezpieczeństwa, na które warto zwrócić uwagę.
Obecność luk w zabezpieczeniach nie jest przeszkodą dla dalszego testowania: ręcznego, integracyjnego lub manualnego. Z drugiej strony, musimy jakoś podnieść bezpieczeństwo produktu, więc aby programiści nie zbagatelizowali tego, co znajduje bezpieczeństwo. Dlatego czasami robimy tak: na stoisku, kiedy produkt trafia na środowisko deweloperskie, po prostu informujemy zespół deweloperski:
— Chłopaki, macie problemy, proszę zwróćcie na nie uwagę.
Na etapie UAT znowu pokazujemy ostrzeżenia o lukach, a na etapie wydania do produkcji mówimy:
— Chłopaki, kilka razy was ostrzegaliśmy, nie zrobiliście nic — z tym nie wypuścimy was.
Jeśli mówimy o kodzie i dynamice, należy pokazywać i ostrzegać o lukach tylko w tych funkcjach i kodzie, który został napisany dopiero w tej funkcji. Если разработчик передвинул кнопочку на 3 пикселя i mówimy mu, że ma tam SQL-iniekcję i że musi to szybko poprawić — to jest nieprawidłowe. Patrzcie tylko na to, co zostało napisane teraz, i na to, co się zmienia w aplikacji.
Powiedzmy, że mamy jakąś funkcjonalną usterkę — to, jak aplikacja nie powinna działać: pieniądze nie są przekazywane, klikając przycisk nie przechodzi na następna stronę lub towar się nie ładuje. Usterki bezpieczeństwa — to takie same usterki, ale nie w kontekście działania aplikacji, a bezpieczeństwa.
Nie wszystkie problemy jakości oprogramowania to problemy bezpieczeństwa. Ale wszystkie problemy bezpieczeństwa są powiązane z jakością oprogramowania. Sherif Mansour, Expedia.
Ponieważ wszystkie luki są takimi samymi usterkami, powinny być traktowane tam samo, gdzie wszystkie usterki rozwojowe. Zapomnijcie o raportach i strasznych PDF-ach, których nikt nie czyta.
Kiedy pracowałem w firmie zajmującej się rozwojem, przyszedł do mnie raport z narzędzi statycznej analizy. Otworzyłem go, przestraszyłem się, zrobiłem kawę, przeszedłem przez 350 stron, zamknąłem i wróciłem do pracy. Duże raporty to martwe raporty. Zwykle nigdzie nie trafiają, e-maile są usuwane, zapominane, gubione lub biznes mówi, że akceptuje ryzyko.
Co robić? Potwierdzone defekty, które znaleźliśmy, po prostu przekształcamy w wygodniejszy do opracowania format, na przykład umieszczamy w backlogu w Jira. Priorytetyzujemy defekty i usuwamy je w kolejności priorytetu, na równi z defektami funkcjonalnymi i defektami testów.
Analiza statyczna — SAST
To analiza kodu pod kątem luk w zabezpieczeniach, ale to nie to samo, co SonarQube. Sprawdzamy nie tylko na podstawie wzorców lub stylu. W analizie stosowane są różne podejścia: według drzewa luk w zabezpieczeniach, według , według analizy plików konfiguracyjnych. To wszystko, co dotyczy bezpośrednio kodu.
Zalety podejścia: wykrywanie luk w zabezpieczeniach w kodzie na wczesnym etapie rozwoju, kiedy jeszcze nie ma środowiska testowego ani gotowego narzędzia, i możliwość inkrementacyjnego skanowania: skanowanie zmienionej części kodu oraz tylko tej funkcjonalności, którą aktualnie przygotowujemy, co skraca czas skanowania.
Minusy — to brak wsparcia dla potrzebnych języków.
Potrzebne integracje, które powinny być w narzędziach, moim subiektywnym zdaniem:
- Narzędzie do integracji: Jenkins, TeamCity i Gitlab CI.
- Środowisko programistyczne: Intellij IDEA, Visual Studio. Programiście łatwiej nie grzebać w niezrozumiałym interfejsie, który jeszcze trzeba zapamiętać, tylko bezpośrednio w jego własnym środowisku deweloperskim widzieć wszystkie potrzebne integracje i luki, które znalazł.
- Przegląd kodu: SonarQube i ręczne przeglądanie.
- Trackery defektów: Jira i Bugzilla.
Na obrazku przedstawiono kilku najlepszych przedstawicieli analizy statycznej.
Ważne są nie narzędzia, a proces, dlatego istnieją rozwiązania open source, które również dobrze nadają się do wypróbowania procesu.
SAST Open Source nie znajdą ogromnej liczby luk w zabezpieczeniach ani skomplikowanych DataFlow, ale przy budowaniu procesu można i należy je wykorzystać. Pomagają zrozumieć, jak będzie zbudowany proces, kto będzie odpowiadał za błędy, kto je zgłasza, kto — raportuje. Jeśli chcesz przeprowadzić początkowy etap budowania bezpieczeństwa swojego kodu — użyj rozwiązań open source.
Jak można to zintegrować, jeśli jesteś na początku drogi, nie masz nic: ani CI, ani Jenkins, ani TeamCity? Rozważmy integracje w procesie.
Integracja na poziomie CVS
Jeśli masz Bitbucket lub GitLab, można przeprowadzić integrację na poziomie .
Na zdarzenie — pull request, commit. Skanujesz kod i w statusie budowy pokazujesz, czy sprawdzenie bezpieczeństwa przeszło, czy nie.
Opinie. Oczywiście, opinie są zawsze potrzebne. Jeśli po prostu wykonałeś pracę po stronie bezpieczeństwa, schowałeś ją do pudełka i nikomu o tym nie powiedziałeś, a potem na koniec miesiąca wypuściłeś mnóstwo błędów — to nie jest w porządku i nie jest dobrze.
Integracja z systemem przeglądu kodu
Pewnego razu w ważnych projektach ustawiliśmy domyślnego recenzenta na użytkownika technicznego AppSec. W zależności od tego, czy w nowym kodzie wykryto błędy, czy nie, na pull request recenzent ustawia status na „akceptuj” lub „wymaga pracy” — albo wszystko OK, albo trzeba poprawić z linkami do tego, co konkretnie poprawić. Na integrację z wersją, która trafia do produkcji, włączyliśmy zakaz scalania, jeśli test z bezpieczeństwa nie został zaliczony. Włączaliśmy to w ręcznym przeglądzie kodu, a inni uczestnicy procesu widzieli statusy bezpieczeństwa właśnie dla tego konkretnego procesu.
Integracja z SonarQube
Wielu ma dla jakości kodu. Tutaj jest to samo — można zrobić te same bramki tylko dla narzędzi SAST. Będzie to samo interfejs, ta sama bramka jakości, tylko będzie się nazywała bramka bezpieczeństwa. I tak, jeśli masz proces z wykorzystaniem SonarQube, można to spokojnie wszystko zintegrować.
Integracja na poziomie CI
Tutaj też wszystko jest dość proste:
- Na jednym poziomie z testami automatycznymi, testami jednostkowymi.
- Podział na etapy rozwoju: dev, test, prod. Mogą być włączane różne zestawy reguł, lub różne warunki niepowodzenia: zatrzymujemy budowę, nie zatrzymujemy budowy.
- Synchronizacja/asynchronizacja uruchamiania. Czekamy na zakończenie testów bezpieczeństwa lub nie czekamy. To znaczy, po prostu je uruchamiamy i idziemy dalej, a potem przychodzi nam status, że wszystko jest dobrze lub źle.
To wszystko w idealnym różowym świecie. W rzeczywistości takiego nie ma, ale dążymy do tego. Wynik przeprowadzonych testów bezpieczeństwa powinien być analogiczny do wyników testów jednostkowych.
Na przykład wzięliśmy duży projekt i zdecydowaliśmy, że teraz będziemy skanować go SAST-em - OK. Wrzuciliśmy ten projekt do SAST, on pokazał nam 20 000 podatności i w ramach decyzji podjęliśmy, że wszystko jest w porządku. 20 000 podatności to nasz dług techniczny. Umieścimy dług w pudełku, będziemy stopniowo go porządkować i zgłaszać błędy w trackerach defektów. Zatrudnimy firmę, zrobimy wszystko sami lub będą nam pomagać Security Champions - i nasz dług techniczny będzie malał.
A wszystkie nowe pojawiające się podatności w nowym kodzie powinny być usuwane tak jak błędy w testach jednostkowych lub automatycznych. Mówiąc obrazowo, rozpoczęła się kompilacja, przeszli przez nią, dwa testy się nie powiodły, a dwa testy bezpieczeństwa. OK - poszliśmy, zobaczyliśmy, co się stało, poprawiliśmy jedno, poprawiliśmy drugie, następnym razem przeszliśmy - wszystko w porządku, nie pojawiły się nowe podatności, testy nie zawiodły. Jeśli zadanie jest głębsze i trzeba je dobrze zrozumieć, lub poprawa podatności dotyczy dużej części tego, co leży pod maską: zgłoszono błąd w trackerze defektów, zostaje on priorytetyzowany i poprawiany. Niestety, świat nie jest idealny i testy czasem się nie powiodą.
Przykład bramy bezpieczeństwa - analog bramy jakości, dotyczący obecności i liczby podatności w kodzie.
Integrujemy z SonarQube - plugin jest instalowany, wszystko jest bardzo wygodne i świetne.
Integracja z środowiskiem deweloperskim
Możliwości integracji:
- Uruchomienie skanowania z środowiska deweloperskiego jeszcze przed commit.
- Przeglądanie wyników.
- Analiza wyników.
- Synchronizacja z serwerem.
Tak mniej więcej wygląda pozyskiwanie wyników z serwera.
W naszym środowisku deweloperskim pojawia się dodatkowy punkt, który informuje, że podczas skanowania znaleziono takie podatności. Można od razu poprawiać kod, oglądać rekomendacje i . Wszystko jest umieszczone w miejscu pracy dewelopera, co jest bardzo wygodne - nie trzeba chodzić po innych linkach i szukać czegoś dodatkowego.
Bardzo interesujące, ale mało znane narzędzie. W naszym przypadku za jego pomocą uruchomimy Juniper vMX i Cisco xRV9000 na zwykłym Ubuntu 20.04 LTS.
To mój ulubiony temat. Wszyscy używają bibliotek Open Source - po co pisać masę obejść i rowerów, gdy można wziąć gotową bibliotekę, w której wszystko jest już wdrożone?
Oczywiście, tak to jest, ale biblioteki są również pisane przez ludzi, zawierają określone ryzyka i zawierają również podatności, o których od czasu do czasu, lub nieustannie, jest mowa. Dlatego istnieje kolejny krok w Bezpieczeństwie Aplikacji – to analiza komponentów Open Source.
Analiza Open Source – OSA
Narzędzie obejmuje trzy dużą etapy.
Wykrywanie podatności w bibliotekach. Na przykład, narzędzie wie, że używamy jakiejś biblioteki, i że w lub w systemie śledzenia błędów są jakieś podatności, które dotyczą tej wersji biblioteki. Przy próbie jej użycia, narzędzie wyda ostrzeżenie, że biblioteka jest podatna i zaleca użycie innej wersji, w której nie ma podatności.
Analiza czystości licencyjnej. Na razie nie jest to u nas szczególnie popularne, ale jeśli pracujesz z zagranicą, to można tam czasami otrzymać naganę za użycie komponentu z otwartym kodem źródłowym, którego nie można używać lub modyfikować. Zgodnie z polityką licencyjną biblioteki, nie możemy tego robić. Albo, jeśli ją zmodyfikowaliśmy i używamy, musimy udostępnić nasz kod. Oczywiście, nikt nie chce publikować kodu swoich produktów, ale również można się przed tym obronić.
Analiza komponentów, które są używane w środowisku przemysłowym. Przypuśćmy hipotetyczną sytuację, że w końcu zakończyliśmy rozwój i wydaliśmy ostatnią wersję naszego mikrousług. On żyje tam wspaniale – tydzień, miesiąc, rok. Nie zbieramy go, nie przeprowadzamy kontroli bezpieczeństwa, wszystko wydaje się dobrze. Ale nagle dwa tygodnie po wydaniu pojawia się krytyczna podatność w komponencie Open Source, który dokładnie w tej wersji używamy w środowisku przemysłowym. Jeśli nie notujemy, co i gdzie używamy, to tej podatności po prostu nie zobaczymy. W niektórych narzędziach istnieje możliwość monitorowania podatności w bibliotekach, które aktualnie są używane w przemyśle. To bardzo pomocne.
Możliwości:
- Różne polityki dla różnych etapów rozwoju.
- Monitorowanie komponentów w środowisku przemysłowym.
- Kontrola bibliotek w obrębie organizacji.
- Wsparcie dla różnych systemów budowy i języków.
- Analiza obrazów Docker.
Kilka przykładów liderów w zakresie analizy Open Source.
Jedyny darmowy z nich to od OWASP. Można go włączyć na wczesnym etapie, aby zobaczyć, jak działa i co obsługuje. W zasadzie to wszystkie produkty chmurowe lub on-premise, ale z ich bazą i tak są wysyłane do internetu. Wysyłają nie twoje biblioteki, a hasze lub swoje wartości, które obliczają, oraz odciski palców do swojego serwera, aby otrzymać powiadomienia o istnieniu luk.
Integracja w procesie
Kontrola bibliotek w perymetrze, które są pobierane z zewnętrznych źródeł. Mamy zewnętrzne i wewnętrzne repozytoria. Na przykład, wewnątrz Event Central stoi Nexus i chcemy, aby w naszym repozytorium nie było luk o statusie „krytyczny” lub „wysoki”. Można skonfigurować proxy przy użyciu narzędzia Nexus Firewall Lifecycle, aby takie luki były odrzucane i nie trafiały do wewnętrznego repozytorium.
Integracja w CI. Na tym samym poziomie co autotesty, testy jednostkowe i podział na etapy rozwoju: dev, test, prod. Na każdym etapie można pobierać dowolne biblioteki, używać czegokolwiek, ale jeśli znajduje się tam coś poważnego o statusie „critical” - być może warto, aby programiści zwrócili na to uwagę na etapie przejścia do produkcji.
Integracja z artefaktoriami: Nexus i JFrog.
Integracja w środowisku deweloperskim. Narzędzia, które wybierasz, powinny mieć integrację ze środowiskami deweloperskimi. Programista powinien mieć dostęp do wyników skanowania z jego miejsca pracy lub możliwość samodzielnego przeskanowania i sprawdzenia kodu pod kątem luk przed wprowadzeniem zmian do CVS.
Integracja w CD. To świetna funkcja, która bardzo mi się podoba, o której już opowiadałem - monitorowanie pojawiania się nowych luk w środowisku przemysłowym. Działa to mniej więcej tak.
Mamy Public Component Repositories — pewne narzędzia z zewnątrz, i nasz wewnętrzny repozytorium. Chcemy, żeby zawierało tylko zaufane komponenty. Przy proksowaniu zapytania sprawdzamy, czy pobierana biblioteka nie ma luk w zabezpieczeniach. Jeśli pasuje do określonych polityk, które ustalamy i musimy uzgodnić z działem rozwoju, nie jest pobierana i pojawia się komunikat o potrzebie użycia innej wersji. W związku z tym, jeśli w bibliotece znajduje się coś naprawdę krytycznego i złego, to programista nie otrzyma jej na etapie instalacji — niech używa wersji wyższej lub niższej.
- Podczas tworzenia builda sprawdzamy, czy nikt nie wstawił niczego złego, czy wszystkie komponenty są bezpieczne i czy nikt nie przyniósł nic niebezpiecznego na pamięci USB.
- W naszym repozytorium znajdują się tylko zaufane komponenty.
- Podczas wdrażania ponownie sprawdzamy same pakiety: war, jar, DL lub obraz Docker, pod kątem zgodności z polityką.
- Podczas przejścia do produkcji monitorujemy to, co dzieje się w środowisku produkcyjnym: pojawiają się lub nie pojawiają krytyczne luki w zabezpieczeniach.
Analiza dynamiczna — DAST
Narzędzia analizy dynamicznej różnią się radykalnie od wszystkiego, co było wcześniej powiedziane. To pewna symulacja pracy użytkownika z aplikacją. Jeśli to aplikacja internetowa, wysyłamy zapytania, symulując pracę klienta, klikamy przyciski na froncie, wysyłamy sztuczne dane z formularzy: cudzysłowy, nawiasy, znaki w różnych kodowaniach, aby zobaczyć, jak aplikacja działa i przetwarza zewnętrzne dane.
Ten sam system pozwala sprawdzać luk w wzorcach w Open Source. Ponieważ DAST nie wie, jakiego Open Source używamy, po prostu rzuca "złośliwe" wzorce i analizuje odpowiedzi serwera:
— Aha, tu jest problem z deserializacją, a tu nie.
To wiąże się z dużymi ryzykami, ponieważ jeśli przeprowadzasz ten test bezpieczeństwa na tym samym środowisku, z którym pracują testerzy — mogą wydarzyć się nieprzyjemne rzeczy.
- Wysokie obciążenie sieci serwera aplikacji.
- Brak integracji.
- Możliwość zmiany ustawień analizowanej aplikacji.
- Brak wsparcia dla niezbędnych technologii.
- Złożoność konfiguracji.
Mieliśmy sytuację, w której w końcu uruchomiliśmy AppScan: długo uzyskiwaliśmy dostęp do aplikacji, dostaliśmy 3 konta i cieszyliśmy się - w końcu wszystko sprawdzimy! Uruchomiliśmy skanowanie, a pierwsze, co zrobił AppScan - wszedł do panelu administracyjnego, przycisnął wszystkie przyciski, zmienił połowę danych, a potem całkowicie zabił serwer swoimi -zapytaniami. Rozwój i testowanie powiedziały:
— Chłopaki, że wy sobie żartujecie?! Daliśmy wam konta, a wy położyliście stand!
Uwzględnij możliwe ryzyka. W idealnym przypadku przygotuj oddzielny stand do testowania bezpieczeństwa, który będzie w jakiś sposób izolowany od reszty środowiska, a kontrolę panelu administracyjnego najlepiej sprawdzać manualnie. To jest test penetracyjny - te pozostałe procenty wysiłku, które teraz nie bierzemy pod uwagę.
Warto zauważyć, że można to wykorzystać jako analogiczne testowanie obciążeniowe. Na pierwszym etapie można włączyć skaner dynamiczny w 10-15 wątkach i zobaczyć, co się stanie, ale zazwyczaj, jak pokazuje praktyka, nic dobrego.
Kilka zasobów, które zwykle używamy.
Warto wyróżnić — to «szwajcarski scyzoryk» dla każdego specjalisty ds. bezpieczeństwa. Używa go wszyscy i jest bardzo wygodny. Właśnie ukazała się nowa wersja demo przedsiębiorstwa. Jeśli wcześniej była to po prostu samodzielna aplikacja z wtyczkami, to teraz w końcu deweloperzy tworzą duży serwer, z którego będzie można zarządzać wieloma agentami. To jest świetne, polecam spróbować.
Integracja w procesie
Integracja przebiega całkiem dobrze i prosto: uruchomienie skanowania po pomyślnej instalacji aplikacji na standzie i skanowanie po pomyślnym przeprowadzeniu testowania integracyjnego.
Jeśli integracje nie działają lub są tam zatyczki i funkcje mock, to jest to bezsensowne i bezużyteczne - niezależnie od tego, jaki wzór wyślemy, serwer i tak będzie odpowiadał tak samo.
- Idealnie - oddzielny stand do testowania.
- Przed rozpoczęciem testowania zapisz sekwencję logowania.
- Testowanie systemu administracyjnego - tylko ręczne.
Proces
Trochę ogólnie o procesie w ogóle i o działaniu każdego narzędzia, w szczególności. Wszystkie aplikacje są różne - w jednej lepiej działa analiza dynamiczna, w innej statyczna, w kolejnej analiza OpenSource, testy penetracyjne lub cokolwiek innego, na przykład zdarzenia z .
Każdy proces wymaga kontroli.
Aby zrozumieć, jak działa proces i gdzie można go poprawić, trzeba zbierać metryki ze wszystkiego, co da się zyskać, w tym metryki produkcyjne, metryki z narzędzi oraz z trackerów defektów.
Jakiekolwiek dane są przydatne. Należy patrzeć z różnych perspektyw na to, gdzie dany instrument jest lepiej stosowany, gdzie proces konkretnie kuleje. Może warto spojrzeć na czas reakcji zespołu developerskiego, aby zrozumieć, gdzie poprawić proces na podstawie czasu. Im więcej danych, tym więcej perspektyw można zbudować, od poziomu ogólnego do szczegółów każdego procesu.
Ponieważ wszystkie analizatory statyczne i dynamiczne mają swoje API, swoje metody uruchamiania, zasady, jedni mają harmonogramy, inni nie — piszemy narzędzie AppSec Orkiestrator, które umożliwia stworzenie jednego punktu wejścia w cały proces z wyrobów i zarządzanie nim z jednego miejsca.
Menadżerowie, programiści i inżynierowie bezpieczeństwa mają jeden punkt wejścia, z którego mogą zobaczyć, co zostało uruchomione, skonfigurować i rozpocząć skanowanie, uzyskać wyniki skanowania, postawić wymagania. Staramy się unikać papierowych dokumentów, przekształcając wszystko w język ludzki, który wykorzystuje rozwój — strony w Confluence z statusem i metrykami, defekty w Jira lub w różnych trackerach defektów, lub integrację w proces synchronizacyjny/asynchroniczny w CI/CD.
Kluczowe wnioski
Narzędzia nie są najważniejsze. Najpierw przemyśl proces — potem wdrażaj narzędzia. Narzędzia są dobre, ale drogie, więc można zacząć od procesu i ustawić współpracę oraz zrozumienie między rozwojem a bezpieczeństwem. Z perspektywy bezpieczeństwa — nie trzeba "zatrzymywać" wszystkiego na raz, z perspektywy rozwoju — jeśli coś jest niezwykle krytyczne, to należy to naprawić, a nie zamykać na problem oczy.
Jakość produktu — wspólny cel zarówno bezpieczeństwa, jak i rozwoju. Wykonujemy tę samą pracę, starając się, aby wszystko działało poprawnie i nie było ryzyk reputacyjnych i strat finansowych. Dlatego propagujemy podejście do DevSecOps, SecDevOps, aby poprawić komunikację i uczynić produkt lepszej jakości.
Zacznij od tego, co już jest: wymagania, architektura, częściowe kontrole, szkolenia, wytyczne. Nie trzeba od razu stosować wszystkich praktyk na wszystkich projektach — działaj iteracyjnie. Nie ma jednego standardu — eksperymentuj i próbuj różnych podejść i rozwiązań.
Między defektami bezpieczeństwa informacji a defektami funkcjonalnymi istnieje znak równości.
Automatyzuj wszystko, co się rusza. Wszystko, co nie rusza — przesuń i zautomatyzuj. Jeśli coś wykonuje się ręcznie, to nie jest dobry obszar procesu. Może powinno się to przemyśleć i również zautomatyzować.
Jeśli zespół ds. bezpieczeństwa informacji jest niewielki — używaj Security Champions.
Możliwe, że to, o czym mówiłem, nie będzie dla Ciebie odpowiednie i wymyślisz coś swojego — i to jest w porządku. Ale wybierz narzędzia w oparciu o wymagania swojego procesu. Nie patrz na to, co mówi społeczność, że to narzędzie jest złe, a to dobre. Może okazać się, że w Twoim produkcie jest przeważnie odwrotnie.
Wymagania dotyczące narzędzi.
- Niski poziom fałszywych alarmów.
- Odpowiedni czas analizy.
- Łatwość użycia.
- Dostępność integracji.
- Zrozumienie roadmapy rozwoju produktu.
- Możliwość dostosowania narzędzi.
Prezentacja Jurija została wybrana jako jedna z najlepszych na DevOpsConf 2018. Aby poznać jeszcze więcej interesujących pomysłów i praktycznych przypadków, przyjdź 27 i 28 maja do Skolkovo na w ramach . A jeszcze lepiej, jeśli jesteś gotów dzielić się swoim doświadczeniem, wtedy na prezentację do 21 kwietnia.
Źródło: habr.com
