Mieliśmy 2 analizatory kodu, 4 narzędzia do testów dynamicznych, własne rzemiosło i 250 skryptów. Nie jest tak, że to wszystko jest potrzebne w bieżącym procesie, ale jak już zaczniesz wdrażać DevSecOps, to trzeba przejść do końca.
. Twórcy postaci: Justin Roiland i Dan Harmon.
Co to jest SecDevOps? A co z DevSecOps? Jakie są różnice? Bezpieczeństwo aplikacji – na czym polega? Dlaczego klasyczne podejście już nie działa? Zna odpowiedź na wszystkie te pytania Jurij Szabalin z Bezpieczeństwo Miecznika. Yuri odpowie na wszystko szczegółowo i przeanalizuje problemy przejścia od klasycznego modelu Application Security do procesu DevSecOps: jak prawidłowo podejść do integracji bezpiecznego procesu deweloperskiego z procesem DevOps i niczego nie popsuć, jak przejść przez główne etapy testów bezpieczeństwa, jakich narzędzi można użyć i czym się różnią oraz jak je poprawnie skonfigurować, aby uniknąć pułapek.
O głośniku: Jurij Szabalin – Główny Architekt Bezpieczeństwa w firmie Bezpieczeństwo Miecznika. Odpowiedzialny za wdrożenie SSDL, za ogólną integrację narzędzi do analizy aplikacji w jednolity ekosystem programistyczny i testowy. 7 lat doświadczenia w bezpieczeństwie informacji. Pracował w Alfa-Bank, Sberbank i Positive Technologies, które zajmują się tworzeniem oprogramowania i dostarczaniem usług. Prelegent na międzynarodowych konferencjach ZeroNights, PHDays, RISSPA, OWASP.
Bezpieczeństwo aplikacji: o co chodzi?
Bezpieczeństwo aplikacji - To jest sekcja bezpieczeństwa odpowiedzialna za bezpieczeństwo aplikacji. Nie dotyczy to infrastruktury czy bezpieczeństwa sieci, a raczej tego, co piszemy i nad czym pracują programiści – to są mankamenty i luki samej aplikacji.
Kierunek - Cykl życia rozwoju zabezpieczeń - opracowany przez Microsoft. Diagram przedstawia kanoniczny model SDLC, którego głównym zadaniem jest udział bezpieczeństwa na każdym etapie rozwoju, od wymagań po wydanie i produkcję. Microsoft zorientował się, że błędów w branży jest za dużo, jest ich więcej i trzeba coś z tym zrobić, i zaproponował takie podejście, które stało się kanoniczne.
Celem Application Security i SSDL nie jest wykrywanie podatności, jak się powszechnie uważa, ale zapobieganie ich wystąpieniu. Z biegiem czasu kanoniczne podejście Microsoftu zostało udoskonalone, rozwinięte i wprowadzone do głębszego, bardziej szczegółowego nurkowania.
Kanoniczny SDLC jest bardzo szczegółowy w różnych metodologiach - OpenSAMM, BSIMM, OWASP. Metodologie są różne, ale ogólnie podobne.
Budowanie bezpieczeństwa w modelu dojrzałości
Najbardziej mi się to podoba BSIMM - . Podstawą metodologii jest podział procesu Bezpieczeństwa Aplikacji na 4 domeny: Governance, Intelligence, SSDL Touchpoints i Deployment. Każda domena ma 12 praktyk, które są reprezentowane jako 112 działań.
Każde ze 112 działań ma 3 poziomy dojrzałości: początkujący, średniozaawansowany i zaawansowany. Możesz przestudiować wszystkie 12 praktyk sekcja po sekcji, wybrać rzeczy, które są dla Ciebie ważne, dowiedzieć się, jak je wdrożyć i stopniowo dodawać elementy, na przykład statyczną i dynamiczną analizę kodu lub przegląd kodu. Zapisujesz plan i spokojnie według niego pracujesz w ramach realizacji wybranych działań.
Dlaczego DevSecOps
DevOps to ogólny, duży proces, w którym trzeba mieć na uwadze bezpieczeństwo.
Początkowo obejmowały kontrole bezpieczeństwa. W praktyce liczba zespołów bezpieczeństwa była znacznie mniejsza niż obecnie i pełniły one nie rolę uczestników procesu, ale organu kontrolno-nadzorczego, który narzuca mu wymagania i sprawdza jakość produktu na koniec wydania. Jest to klasyczne podejście, w którym zespoły bezpieczeństwa znajdowały się za ścianą od rozwoju i nie brały udziału w procesie.
Głównym problemem jest to, że bezpieczeństwo informacji jest oddzielone od rozwoju. Zwykle jest to jakiś obwód bezpieczeństwa informacji i zawiera 2-3 duże i drogie narzędzia. Raz na sześć miesięcy przychodzi kod źródłowy lub aplikacja, które należy sprawdzić, a raz w roku są one produkowane . Wszystko to prowadzi do tego, że data premiery dla branży jest opóźniona, a deweloper narażony jest na ogromną liczbę luk ze zautomatyzowanych narzędzi. Nie da się tego wszystkiego rozebrać i naprawić, bo wyniki z poprzednich sześciu miesięcy nie zostały uporządkowane, ale oto nowa partia.
W trakcie pracy naszej firmy widzimy, że bezpieczeństwo we wszystkich obszarach i branżach rozumie, że czas nadrobić zaległości i kręcić się z rozwojem na tym samym kole – w . Paradygmat DevSecOps doskonale wpisuje się w zwinną metodologię programowania, wdrażanie, wsparcie i udział w każdym wydaniu i iteracji.
Przejście do DevSecOps
Najważniejszym słowem w cyklu życia rozwoju zabezpieczeń jest "proces". Musisz to zrozumieć, zanim pomyślisz o zakupie narzędzi.
Samo włączenie narzędzi do procesu DevOps nie wystarczy – ważna jest komunikacja i zrozumienie pomiędzy uczestnikami procesu.
Ważniejsi są ludzie, a nie narzędzia.
Często planowanie bezpiecznego procesu rozwoju zaczyna się od wyboru i zakupu narzędzia, a kończy na próbach włączenia narzędzia do bieżącego procesu, które pozostają próbami. Prowadzi to do niefortunnych konsekwencji, ponieważ wszystkie narzędzia mają swoje własne cechy i ograniczenia.
Częstym przypadkiem jest sytuacja, gdy dział bezpieczeństwa wybrał dobre, drogie narzędzie o szerokich możliwościach i przyszedł do programistów, aby zintegrowali go z procesem. Ale to nie wychodzi – proces jest tak skonstruowany, że ograniczenia zakupionego już narzędzia nie mieszczą się w dotychczasowym paradygmacie.
Najpierw opisz, jakiego rezultatu oczekujesz i jak będzie wyglądał proces. Pomoże to zrozumieć rolę narzędzia i bezpieczeństwa w procesie.
Zacznij od tego, co jest już w użyciu
Zanim kupisz drogie narzędzia, spójrz, co już masz. Każda firma ma wymagania bezpieczeństwa rozwoju, są czeki, pentesty – dlaczego by tego wszystkiego nie przełożyć na formę zrozumiałą i wygodną dla każdego?
Zwykle wymaganiami jest papierowy Talmud, który leży na półce. Zdarzyło się, że przyszliśmy do firmy przyjrzeć się procesom i zapytać o wymagania bezpieczeństwa dotyczące oprogramowania. Specjalista, który się tym zajmował, długo szukał:
- Teraz gdzieś w notatkach była ścieżka, gdzie leży ten dokument.
W rezultacie dokument otrzymaliśmy tydzień później.
Dla wymagań, kontroli i innych rzeczy utwórz stronę np. Zbieg - jest to wygodne dla każdego.
Łatwiej jest sformatować to, co już masz i użyć go na początek.
Użyj Mistrzów Bezpieczeństwa
Zazwyczaj w przeciętnej firmie zatrudniającej 100-200 programistów jest jeden specjalista ds. bezpieczeństwa, który wykonuje kilka funkcji i nie ma fizycznie czasu, aby wszystko sprawdzić. Nawet jeśli dołoży wszelkich starań, sam nie sprawdzi całego kodu generowanego przez program. Dla takich przypadków opracowano koncepcję - .
Mistrzowie Bezpieczeństwa to osoby w zespole programistów zainteresowane bezpieczeństwem Twojego produktu.
Security Champion to punkt wejścia do zespołu programistów i ewangelista bezpieczeństwa w jednym.
Zwykle, gdy specjalista ds. bezpieczeństwa przychodzi do zespołu programistów i wskazuje błąd w kodzie, otrzymuje zdziwioną odpowiedź:
- I kim jesteś? Widzę cię po raz pierwszy. U mnie wszystko w porządku – starszy przyjaciel dał mi „aplikację” na recenzję kodu, ruszamy dalej!
Jest to typowa sytuacja, ponieważ znacznie większe zaufanie darzą seniorzy lub po prostu koledzy z zespołu, z którymi programista stale współpracuje w pracy i przy przeglądaniu kodu. Jeżeli zamiast ochroniarza Mistrz Bezpieczeństwa wskaże błąd i konsekwencje, wówczas jego słowo będzie miało większą wagę.
Ponadto programiści znają swój kod lepiej niż jakikolwiek specjalista ds. bezpieczeństwa. Osobie, która ma przynajmniej 5 projektów w narzędziu do analizy statycznej, zazwyczaj trudno jest zapamiętać wszystkie niuanse. Mistrzowie Bezpieczeństwa znają swój produkt: co z czym współdziała i na co zwrócić uwagę w pierwszej kolejności – są bardziej skuteczni.
Zastanów się więc nad wdrożeniem Mistrzów Bezpieczeństwa i rozszerzeniem wpływu swojego zespołu ds. bezpieczeństwa. Przydaje się to również samemu mistrzowi: rozwój zawodowy w nowej dziedzinie, poszerzanie horyzontów technicznych, podnoszenie umiejętności technicznych, menadżerskich i przywódczych, zwiększanie wartości rynkowej. To jakiś element socjotechniki, Twoje „oczy” w zespole programistów.
Etapy testowania
mówi, że 20% wysiłku daje 80% rezultatów. Te 20% to praktyki analizy aplikacji, które można i należy zautomatyzować. Przykładami takich działań są analizy statyczne - SAST, analiza dynamiczna - DZIEŃ и Kontrola Open Source. Opowiem Ci bardziej szczegółowo o działaniach, a także o narzędziach, z jakimi funkcjami najczęściej spotykamy się wprowadzając je do procesu i jak to zrobić poprawnie.
Główne problemy narzędzi
Podkreślę problemy, które są istotne dla wszystkich instrumentów i wymagają uwagi. Przeanalizuję je bardziej szczegółowo, aby ich więcej nie powtarzać.
Długi czas analizy. Jeśli od zatwierdzenia do wydania zajmie to 30 minut na wszystkie testy i montaż, wówczas kontrola bezpieczeństwa informacji zajmie jeden dzień. Nikt więc nie będzie spowalniał tego procesu. Weź tę cechę pod uwagę i wyciągnij wnioski.
Wysoki poziom fałszywie ujemny lub fałszywie dodatni. Wszystkie produkty są różne, wszystkie korzystają z różnych frameworków i własnego stylu kodowania. W przypadku różnych baz kodu i technologii narzędzia mogą pokazywać różne poziomy wyników fałszywie ujemnych i fałszywie pozytywnych. Sprawdź więc, co dokładnie jest w środku swój firmy i dla swój aplikacje dadzą dobre i wiarygodne wyniki.
Brak integracji z istniejącymi narzędziami. Spójrz na narzędzia pod kątem integracji z tym, czego już używasz. Przykładowo, jeśli posiadasz Jenkinsa lub TeamCity, sprawdź integrację narzędzi z tym oprogramowaniem, a nie z GitLab CI, z którego nie korzystasz.
Brak lub nadmierna złożoność dostosowywania. Jeśli narzędzie nie ma interfejsu API, to dlaczego jest potrzebne? Wszystko co da się zrobić w interfejsie powinno być dostępne poprzez API. W idealnym przypadku narzędzie powinno mieć możliwość dostosowywania kontroli.
Brak planu rozwoju produktu. Rozwój nie stoi w miejscu, cały czas korzystamy z nowych frameworków i funkcji, przepisując stary kod na nowe języki. Chcemy mieć pewność, że kupowane przez nas narzędzie będzie wspierać nowe frameworki i technologie. Dlatego ważne jest, aby wiedzieć, że produkt jest prawdziwy i poprawny rozwój.
Funkcje procesowe
Oprócz funkcji narzędzi, należy wziąć pod uwagę cechy procesu rozwoju. Częstym błędem jest na przykład utrudnianie rozwoju. Przyjrzyjmy się, jakie jeszcze cechy warto wziąć pod uwagę i na co powinna zwrócić uwagę ekipa ds. bezpieczeństwa.
Aby nie przegapić terminów rozwoju i wydania, utwórz różne zasady i różne pokaż korki — kryteria zatrzymania procesu kompilacji w przypadku obecności luk — dla różnych środowisk. Rozumiemy np., że obecna gałąź trafia na stanowisko deweloperskie czyli UAT, co oznacza, że nie zatrzymujemy się i nie mówimy:
„Macie tu słabe punkty, dalej nie pójdziecie!”
W tym momencie ważne jest, aby powiedzieć programistom, że istnieją problemy związane z bezpieczeństwem, które wymagają uwagi.
Obecność luk nie stanowi przeszkody w dalszych testach: ręczny, integracyjny lub ręczny. Z drugiej strony musimy w jakiś sposób zwiększyć bezpieczeństwo produktu, aby programiści nie zaniedbywali tego, co uważają za bezpieczne. Dlatego czasami tak robimy: na stoisku, gdy jest on wdrażany na środowisko programistyczne, po prostu powiadamiamy o rozwoju:
- Chłopaki, macie problemy, proszę, zwróćcie na nie uwagę.
Na etapie UAT ponownie wyświetlamy ostrzeżenia o lukach, a na etapie wydania mówimy:
- Chłopaki, ostrzegaliśmy was kilka razy, nic nie zrobiliście - nie wypuścimy was z tym.
Jeśli mówimy o kodzie i dynamice, to konieczne jest pokazanie i ostrzeżenie o lukach tylko w tych funkcjach i kodzie, który właśnie został napisany w tej funkcji. Jeśli programista przesunie przycisk o 3 piksele, a my powiemy mu, że ma tam zastrzyk SQL i dlatego należy go pilnie naprawić, jest to błędne. Spójrz tylko na to, co jest napisane teraz i na zmianę, która nastąpi w aplikacji.
Załóżmy, że mamy pewną wadę funkcjonalną - sposób, w jaki aplikacja nie powinna działać: pieniądze nie są przesyłane, po kliknięciu przycisku nie następuje przejście do następnej strony lub produkt się nie ładuje. Wady bezpieczeństwa - to są te same wady, tyle że nie w działaniu aplikacji, a w bezpieczeństwie.
Nie wszystkie problemy z jakością oprogramowania są problemami związanymi z bezpieczeństwem. Ale wszystkie problemy związane z bezpieczeństwem są związane z jakością oprogramowania. Szeryf Mansour, Expedia.
Ponieważ wszystkie podatności są tymi samymi defektami, powinny być zlokalizowane w tym samym miejscu, co wszystkie defekty rozwojowe. Zapomnij więc o raportach i strasznych plikach PDF, których nikt nie czyta.
Kiedy pracowałem w firmie deweloperskiej, otrzymałem raport z narzędzi do analizy statycznej. Otworzyłem, byłem przerażony, zrobiłem kawę, przekartkowałem 350 stron, zamknąłem i zabrałem się do pracy. Duże raporty to martwe raporty. Zwykle nigdzie nie trafiają, listy są usuwane, zapominane, gubione lub firma twierdzi, że akceptuje ryzyko.
Co robić? Potwierdzone defekty, które znaleźliśmy, po prostu konwertujemy do formy wygodnej do rozwoju, np. umieszczamy je w backlogu w Jirze. Nadajemy priorytet defektom i eliminujemy je w kolejności ważności, wraz z defektami funkcjonalnymi i defektami testowymi.
Analiza statyczna - SAST
To jest analiza kodu pod kątem luk., ale to nie to samo co SonarQube. Nie sprawdzamy tylko wzorów i stylu. W analizie wykorzystuje się szereg podejść: według drzewa podatności, wg , analizując pliki konfiguracyjne. To wszystko, co dotyczy samego kodu.
Plusy podejścia: identyfikacja luk w kodzie już na wczesnym etapie jego rozwojugdy nie ma jeszcze stojaków ani gotowych narzędzi, oraz możliwość skanowania przyrostowego: skanowanie części kodu, która uległa zmianie i tylko tej funkcji, którą aktualnie wykonujemy, co skraca czas skanowania.
Wady - jest to brak wsparcia dla niezbędnych języków.
Niezbędne integracje, które moim zdaniem powinny znaleźć się w narzędziach:
- Narzędzie do integracji: Jenkins, TeamCity i Gitlab CI.
- Środowisko programistyczne: Intellij IDEA, Visual Studio. Dla programisty wygodniej jest nie poruszać się po niezrozumiałym interfejsie, który trzeba zapamiętać, ale zobaczyć wszystkie niezbędne integracje i luki, które znalazł bezpośrednio w miejscu pracy, we własnym środowisku programistycznym.
- Recenzja kodu: SonarQube i recenzja ręczna.
- Narzędzia do śledzenia defektów: Jira i Bugzilla.
Na zdjęciu niektórzy z najlepszych przedstawicieli analizy statycznej.
Nie narzędzia są ważne, ale proces, dlatego istnieją rozwiązania Open Source, które nadają się również do testowania procesu.
SAST Open Source nie znajdzie ogromnej liczby podatności ani skomplikowanych DataFlows, ale można i należy je wykorzystać podczas budowania procesu. Pomagają zrozumieć, jak będzie zbudowany proces, kto będzie reagował na błędy, kto będzie raportował i kto będzie raportował. Jeśli chcesz przeprowadzić początkowy etap budowania bezpieczeństwa swojego kodu, skorzystaj z rozwiązań Open Source.
Jak można to zintegrować, jeśli jesteś na początku swojej podróży i nie masz nic: żadnego CI, żadnego Jenkinsa, żadnego TeamCity? Rozważmy integrację z procesem.
Integracja na poziomie CVS
Jeśli posiadasz Bitbucket lub GitLab, możesz przeprowadzić integrację na poziomie .
Według wydarzenia - żądanie ściągnięcia, zatwierdzenie. Skanujesz kod, a status kompilacji pokazuje, czy kontrola bezpieczeństwa przebiegła pomyślnie, czy nie.
Informacje zwrotne Oczywiście informacja zwrotna jest zawsze potrzebna. Jeśli po prostu zrobiłeś zabezpieczenia na boku, włóż je do pudełka i nikomu nic o tym nie mów, a potem pod koniec miesiąca wyrzuciłeś masę błędów - to nie jest poprawne i niedobre.
Integracja z systemem przeglądu kodu
Kiedyś występowaliśmy jako domyślny recenzent dla technicznego użytkownika AppSec w wielu ważnych projektach. W zależności od tego, czy w nowym kodzie wykryto błędy, czy też nie ma żadnych błędów, recenzent ustawia status pull requesta na „akceptuję” lub „wymaga pracy” – albo wszystko jest w porządku, albo linki do tego, co dokładnie należy poprawić trzeba poprawić. W celu integracji z wersją, która wchodzi do produkcji, włączyliśmy zakaz łączenia w przypadku niezaliczenia testu bezpieczeństwa informacji. Uwzględniliśmy to w ręcznym przeglądzie kodu, a inni uczestnicy procesu widzieli statusy bezpieczeństwa tego konkretnego procesu.
Integracja z SonarQube
Wielu tak pod względem jakości kodu. Tutaj jest tak samo – takie same bramki można wykonać tylko dla narzędzi SAST. Będzie ten sam interfejs, ta sama bramka jakości, tylko będzie wywoływana Brama bezpieczeństwa. Ponadto, jeśli masz proces wykorzystujący SonarQube, możesz łatwo zintegrować wszystko w tym procesie.
Integracja na poziomie CI
Wszystko tutaj jest również dość proste:
- Na równi z autotestami, testy jednostkowe.
- Podział ze względu na etapy rozwoju: deweloper, test, prod. Mogą zostać uwzględnione różne zestawy reguł lub różne warunki niepowodzenia: zatrzymaj montaż, nie zatrzymuj montażu.
- Uruchamianie synchroniczne/asynchroniczne. Czekamy na zakończenie testów bezpieczeństwa lub nie. Czyli po prostu je uruchomiliśmy i idziemy dalej, po czym dostajemy status, że wszystko jest dobrze lub źle.
To wszystko w idealnym różowym świecie. W prawdziwym życiu czegoś takiego nie ma, ale staramy się. Wynik przeprowadzenia kontroli bezpieczeństwa powinien być podobny do wyników testów jednostkowych.
Przykładowo wzięliśmy duży projekt i zdecydowaliśmy, że teraz zeskanujemy go SASTem - OK. Wrzuciliśmy ten projekt do SAST, dał nam 20 000 luk w zabezpieczeniach i zdecydowaną decyzją zdecydowaliśmy, że wszystko jest w porządku. 20 000 luk to nasz dług techniczny. Umieścimy dług w pudełku, powoli go sprzątniemy i dodamy błędy do trackerów defektów. Zatrudnijmy firmę, zróbmy wszystko sami lub poprośmy o pomoc Mistrzów Bezpieczeństwa – a dług technologiczny zmniejszy się.
A wszystkie nowo pojawiające się luki w nowym kodzie trzeba eliminować w taki sam sposób, jak błędy w jednostce czy w autotestach. Relatywnie rzecz biorąc, montaż się rozpoczął, przeprowadziliśmy go, dwa testy i dwa testy bezpieczeństwa nie powiodły się. OK – pojechaliśmy, sprawdziliśmy, co się stało, naprawiliśmy jedno, poprawiliśmy drugie, uruchomiliśmy następnym razem – wszystko było w porządku, nie pojawiły się żadne nowe luki, żadne testy nie zakończyły się niepowodzeniem. Jeśli to zadanie jest głębsze i musisz je dobrze zrozumieć lub naprawianie luk wpływa na duże warstwy tego, co kryje się pod maską: do narzędzia do śledzenia defektów dodano błąd, jest on traktowany priorytetowo i naprawiany. Niestety świat nie jest idealny i testy czasami zawodzą.
Przykładem bramki bezpieczeństwa jest odpowiednik bramki jakości pod względem obecności i liczby luk w kodzie.
Integrujemy się z SonarQube - wtyczka jest zainstalowana, wszystko jest bardzo wygodne i fajne.
Integracja ze środowiskiem deweloperskim
Opcje integracji:
- Uruchamianie skanowania ze środowiska programistycznego przed zatwierdzeniem.
- Pokaż wyniki.
- Analiza wyników.
- Synchronizacja z serwerem.
Tak wygląda otrzymanie wyników z serwera.
W naszym środowisku programistycznym po prostu pojawia się dodatkowy element informujący, że podczas skanowania wykryto takie luki. Możesz od razu edytować kod, przeglądać rekomendacje i . To wszystko znajduje się w miejscu pracy programisty, co jest bardzo wygodne – nie ma potrzeby klikania w inne linki i szukania czegoś dodatkowego.
open Source
To mój ulubiony temat. Wszyscy korzystają z bibliotek Open Source – po co pisać masę kul i rowerów, skoro można wziąć gotową bibliotekę, w której wszystko jest już zaimplementowane?
Oczywiście to prawda, ale biblioteki również są pisane przez ludzi, one też niosą ze sobą pewne zagrożenia, a także istnieją luki, które są zgłaszane okresowo lub stale. Zatem następuje kolejny krok w Bezpieczeństwie Aplikacji – jest to analiza komponentów Open Source.
Analiza Open Source - OSA
Narzędzie składa się z trzech dużych etapów.
Wyszukiwanie podatności w bibliotekach. Narzędzie np. wie, że korzystamy z jakiejś biblioteki i że w lub istnieją pewne luki w modułach śledzenia błędów, które dotyczą tej wersji biblioteki. Przy próbie użycia narzędzie wyświetli ostrzeżenie, że biblioteka jest podatna na ataki i zasugeruje użycie innej wersji, która nie zawiera luk.
Analiza czystości licencji. Nie jest to jeszcze tutaj szczególnie popularne, ale jeśli pracujesz za granicą, to od czasu do czasu możesz tam dostać podatek za korzystanie z komponentu open source, którego nie można używać ani modyfikować. Zgodnie z polityką licencjonowanej biblioteki nie możemy tego zrobić. Lub, jeśli go zmodyfikowaliśmy i użyliśmy, powinniśmy opublikować nasz kod. Oczywiście nikt nie chce publikować kodu swoich produktów, ale można się też przed tym zabezpieczyć.
Analiza komponentów używanych w środowisku przemysłowym. Wyobraźmy sobie hipotetyczną sytuację, że w końcu zakończyliśmy prace rozwojowe i wypuściliśmy najnowszą wersję naszego mikroserwisu. Żyje się tam cudownie – tydzień, miesiąc, rok. Nie zbieramy, nie przeprowadzamy kontroli bezpieczeństwa, wszystko wydaje się być w porządku. Ale nagle, dwa tygodnie po wydaniu, w komponencie Open Source, którego używamy w tej konkretnej wersji, w środowisku przemysłowym, pojawia się krytyczna luka w zabezpieczeniach. Jeśli nie zarejestrujemy, czego i gdzie używamy, po prostu nie zobaczymy tej luki. Niektóre narzędzia mają możliwość monitorowania podatności w bibliotekach, które są obecnie używane w branży. To jest bardzo użyteczne.
Cechy:
- Różne polityki dla różnych etapów rozwoju.
- Monitorowanie komponentów w środowisku przemysłowym.
- Kontrola bibliotek w organizacji.
- Obsługa różnych systemów kompilacji i języków.
- Analiza obrazów Dockera.
Kilka przykładów liderów branży zajmujących się analizą Open Source.
Jedyny darmowy to ten z OWASP. Można go włączyć w pierwszych etapach, zobaczyć jak działa i co obsługuje. W zasadzie są to wszystkie produkty chmurowe, czyli on-premise, jednak za swoją bazą nadal przesyłane są do Internetu. Wysyłają nie Twoje biblioteki, ale skróty lub własne wartości, które wyliczają, oraz odciski palców na swój serwer, aby otrzymać informację o obecności luk.
Integracja procesów
Kontrola obwodowa bibliotek, które są pobierane ze źródeł zewnętrznych. Posiadamy repozytoria zewnętrzne i wewnętrzne. Na przykład Event Central obsługuje Nexusa i chcemy mieć pewność, że w naszym repozytorium nie ma luk o statusie „krytycznym” lub „wysokim”. Możesz skonfigurować proxy za pomocą narzędzia cyklu życia zapory Nexus, dzięki czemu takie luki zostaną odcięte i nie trafią do wewnętrznego repozytorium.
Integracja z CI. Na tym samym poziomie co autotesty, testy jednostkowe i podział na etapy rozwoju: dev, test, prod. Na każdym etapie można pobrać dowolne biblioteki, skorzystać z czegokolwiek, jednak jeśli jest coś trudnego ze statusem „krytyczny”, być może warto zwrócić na to uwagę programistów na etapie wypuszczania do produkcji.
Integracja z artefaktami: Nexus i JFrog.
Integracja ze środowiskiem programistycznym. Wybrane narzędzia powinny mieć integrację ze środowiskami programistycznymi. Programista musi mieć dostęp do wyników skanowania ze swojego miejsca pracy lub możliwość samodzielnego zeskanowania i sprawdzenia kodu pod kątem luk w zabezpieczeniach przed przystąpieniem do CVS.
Integracja z płytą CD. To fajna funkcja, która bardzo mi się podoba i o której już mówiłem - monitorowanie pojawiania się nowych podatności w środowisku przemysłowym. Działa mniej więcej tak.
Mamy Publiczne repozytoria komponentów — niektóre narzędzia na zewnątrz i nasze wewnętrzne repozytorium. Zależy nam, aby zawierał wyłącznie zaufane komponenty. Podczas proxy żądania sprawdzamy, czy pobrana biblioteka nie ma luk w zabezpieczeniach. Jeśli podlega określonym przez nas zasadom i koniecznie jest skoordynowany z rozwojem, nie przesyłamy go i pojawia się monit o użycie innej wersji. Odpowiednio, jeśli w bibliotece jest coś naprawdę krytycznego i złego, programista nie otrzyma biblioteki na etapie instalacji - niech użyje wersji wyższej lub niższej.
- Podczas budowy sprawdzamy, czy nikomu nic złego się nie poślizgnęło, czy wszystkie elementy są bezpieczne i nikt nie wniósł na pendrive niczego niebezpiecznego.
- W repozytorium mamy tylko zaufane komponenty.
- Podczas wdrażania ponownie sprawdzamy sam pakiet: war, jar, DL lub obraz Dockera, aby upewnić się, że jest on zgodny z polityką.
- Wchodząc do branży monitorujemy co dzieje się w środowisku przemysłowym: pojawiają się lub nie pojawiają się krytyczne podatności.
Analiza dynamiczna - DAST
Narzędzia do analizy dynamicznej zasadniczo różnią się od wszystkiego, co zostało powiedziane wcześniej. Jest to swego rodzaju imitacja pracy użytkownika z aplikacją. Jeżeli jest to aplikacja internetowa to wysyłamy żądania symulując pracę klienta, klikamy w przyciski z przodu, przesyłamy sztuczne dane z formularza: cudzysłowy, nawiasy, znaki w różnym kodowaniu, aby zobaczyć jak aplikacja działa i przetwarza Dane zewnętrzne.
Ten sam system pozwala sprawdzić podatności szablonów w Open Source. Ponieważ DAST nie wie, jakiego Open Source używamy, po prostu rzuca „złośliwe” wzorce i analizuje odpowiedzi serwera:
- Tak, tutaj jest problem z deserializacją, ale nie tutaj.
Ryzyko jest w tym duże, ponieważ jeśli przeprowadzisz ten test bezpieczeństwa na tym samym stanowisku, na którym pracują testerzy, mogą wydarzyć się nieprzyjemne rzeczy.
- Duże obciążenie sieci serwerów aplikacji.
- Żadnych integracji.
- Możliwość zmiany ustawień analizowanej aplikacji.
- Nie ma wsparcia dla niezbędnych technologii.
- Trudność w konfiguracji.
Mieliśmy taką sytuację, kiedy w końcu uruchomiliśmy AppScan: długo próbowaliśmy uzyskać dostęp do aplikacji, mamy 3 konta i jesteśmy szczęśliwi – w końcu wszystko sprawdzimy! Uruchomiliśmy skanowanie i pierwszą rzeczą, którą zrobił AppScan, było wejście do panelu administracyjnego, przebicie wszystkich przycisków, zmiana połowy danych, a następnie całkowite zabicie serwera jego -upraszanie. Rozwój z testowaniem powiedział:
- Chłopaki, żartujecie sobie?! Daliśmy wam konta, a wy ustawiliście stoisko!
Rozważ możliwe ryzyko. Idealnie byłoby przygotować osobne stanowisko do testowania bezpieczeństwa informacji, które będzie przynajmniej w jakiś sposób odizolowane od reszty otoczenia i warunkowo sprawdzić panel administracyjny, najlepiej w trybie ręcznym. To jest pentest – pozostały procent wysiłku, którego teraz nie bierzemy pod uwagę.
Warto wziąć pod uwagę, że można to wykorzystać jako analogię do testowania obciążenia. Na pierwszym etapie możesz włączyć skaner dynamiczny z 10-15 wątkami i zobaczyć, co się stanie, ale zwykle, jak pokazuje praktyka, nic dobrego.
Kilka zasobów, z których zwykle korzystamy.
Warte podkreślenia to „szwajcarski nóż” dla każdego specjalisty ds. ochrony. Każdy z tego korzysta i jest to bardzo wygodne. Została udostępniona nowa wersja demonstracyjna wersji Enterprise. Jeśli wcześniej było to tylko samodzielne narzędzie z wtyczkami, teraz programiści w końcu tworzą duży serwer, z którego będzie można zarządzać kilkoma agentami. To jest fajne, polecam spróbować.
Integracja procesów
Integracja przebiega całkiem dobrze i prosto: rozpocznij skanowanie po pomyślnej instalacji aplikacje na stojak i skanowanie po pomyślnych testach integracji.
Jeżeli integracje nie działają lub występują zamienniki i próbne funkcje, jest to bezcelowe i bezużyteczne – niezależnie od tego, jaki wzór wyślemy, serwer i tak odpowie w ten sam sposób.
- Idealnie byłoby osobne stanowisko testowe.
- Przed testowaniem zapisz sekwencję logowania.
- Testowanie systemu administracyjnego odbywa się wyłącznie ręcznie.
proces
Trochę uogólnione na temat procesu w ogóle i działania każdego narzędzia w szczególności. Wszystkie aplikacje są różne - jedna lepiej radzi sobie z analizą dynamiczną, inna z analizą statyczną, trzecia z analizą OpenSource, pentestami, a może zupełnie czymś innym, np. zdarzeniami .
Każdy proces wymaga kontroli.
Aby zrozumieć, jak działa proces i gdzie można go ulepszyć, musisz zebrać metryki ze wszystkiego, co możesz dostać, w tym metryki produkcyjne, metryki z narzędzi i narzędzia do śledzenia defektów.
Każda informacja jest pomocna. Konieczne jest spojrzenie pod różnymi kątami na to, gdzie lepiej zastosować to lub inne narzędzie, gdzie proces szczególnie się załamuje. Warto przyjrzeć się czasom reakcji programistów, aby zobaczyć, gdzie można ulepszyć proces w oparciu o czas. Im więcej danych, tym więcej sekcji można zbudować od najwyższego poziomu do szczegółów każdego procesu.
Ponieważ wszystkie analizatory statyczne i dynamiczne mają własne API, własne metody uruchamiania, zasady, niektóre mają harmonogramy, inne nie - piszemy narzędzie Orkiestrator AppSec, co pozwala stworzyć jeden punkt wejścia do całego procesu z poziomu produktu i zarządzać nim z jednego punktu.
Menedżerowie, programiści i inżynierowie bezpieczeństwa mają jeden punkt wejścia, z którego mogą zobaczyć, co jest uruchomione, skonfigurować i uruchomić skanowanie, otrzymać wyniki skanowania i przesłać wymagania. Staramy się odejść od papierkowej roboty, wszystko przełożyć na ludzki, z czego korzysta developer - strony na Confluence ze statusami i metrykami, defekty w Jira czy w różnych trackerach defektów, czy integracja z procesem synchronicznym/asynchronicznym w CI /PŁYTA CD.
Na wynos
Narzędzia nie są najważniejsze. Najpierw przemyśl proces, a następnie zastosuj narzędzia. Narzędzia są dobre, ale drogie, więc możesz zacząć od procesu i budować komunikację i zrozumienie między rozwojem a bezpieczeństwem. Z punktu widzenia bezpieczeństwa nie ma potrzeby „zatrzymywania” wszystkiego.Z punktu widzenia rozwoju, jeśli jest coś mega superkrytycznego, to należy to wyeliminować, a nie przymykać oczy na problem.
Jakość produktu - wspólny cel zarówno bezpieczeństwo, jak i rozwój. Robimy jedno, staramy się, aby wszystko działało poprawnie i nie było ryzyka reputacji ani strat finansowych. Dlatego promujemy podejście DevSecOps, SecDevOps, aby usprawnić komunikację i poprawić jakość produktu.
Zacznij od tego, co już masz: wymagania, architektura, kontrole cząstkowe, szkolenia, wytyczne. Nie ma potrzeby od razu stosować wszystkich praktyk do wszystkich projektów - poruszaj się iteracyjnie. Nie ma jednego standardu – eksperyment i wypróbuj różne podejścia i rozwiązania.
Istnieje znak równości pomiędzy wadami bezpieczeństwa informacji i wadami funkcjonalnymi.
Zautomatyzuj wszystkoto się porusza. Cokolwiek się nie porusza, przenieś to i zautomatyzuj. Jeśli coś jest robione ręcznie, nie jest to dobra część procesu. Być może warto to sprawdzić i zautomatyzować.
Jeśli wielkość zespołu IS jest niewielka – użyj Mistrzów Bezpieczeństwa.
Być może to, o czym mówiłem, nie będzie Ci odpowiadać i wymyślisz coś własnego - i to dobrze. Ale wybierz narzędzia w oparciu o wymagania Twojego procesu. Nie patrz na to, co mówi społeczność, że to narzędzie jest złe, a to dobre. Być może w przypadku Twojego produktu będzie odwrotnie.
Wymagania dotyczące narzędzi.
- Niski poziom fałszywie dodatni.
- Odpowiedni czas analizy.
- Wygoda użytkowania.
- Dostępność integracji.
- Zrozumienie planu rozwoju produktu.
- Możliwość personalizacji narzędzi.
Raport Yuriego został uznany za jeden z najlepszych na DevOpsConf 2018. Aby zapoznać się z jeszcze ciekawszymi pomysłami i praktycznymi przykładami, przyjedź do Skołkowa 27 i 28 maja w . Jeszcze lepiej, jeśli jesteś gotowy podzielić się swoim doświadczeniem na sprawozdanie do 21 kwietnia.
Źródło: www.habr.com