Stosowanie podejścia do ciągłego cyklu tworzenia zabezpieczeń (Continuous SDL)

Innowacje to życie organizacji w epoce cyfrowej i musi być zarówno włączone, jak i chronione. Bezpieczeństwo innowacji chroni procesy i dane innowacji przed cyberatakami. Innowacje w epoce cyfrowej mają formę tworzenia aplikacji przy użyciu metody DevOps lub DevSecOps . Takie podejście umożliwia organizacjom szybkie wprowadzanie innowacji bez oczekiwania na tradycyjne harmonogramy statków kaskadowych, które mogą potrwać miesiące lub lata między wydaniami.

Pomyślne możliwości i aplikacje spełniają trzy różne typy wymagań:

• Funkcjonalne (deweloperskie): Aplikacja musi spełniać potrzeby biznesowe i użytkownika, które często szybko ewoluują.
• Bezpieczna (s): Aplikacja musi być odporna na ataki przed szybko zmieniającymi się osobami atakującymi i korzystać z innowacji w zabezpieczeniach.
• Niezawodne (operacje): Aplikacja musi być niezawodna i wydajna.

Scalanie tych trzech wymagań razem i tworzenie kultury udostępnionej jest niezwykle ważne, ale często trudne. Liderzy zespołów programistycznych, IT i zabezpieczeń muszą współpracować, aby zwiększyć tę zmianę.

Obejrzyj poniższy film wideo, aby dowiedzieć się więcej o metodzie DevSecOps w celu zapewnienia bezpieczeństwa i szybkiego innowacji.

Integrowanie zabezpieczeń w całym cyklu życia programowania

Ważne jest, aby zintegrować zabezpieczenia w całym cyklu projektowania, aby szybko identyfikować i poprawiać projekt, kod i inne problemy na wczesnym etapie, gdy ludzie pracują nad tym procesem. Takie podejście pozwala uniknąć droższych i trudnych poprawek później, które mogą spowodować dużą ilość przepracowania.

Zagrożenia bezpieczeństwa (i konieczność ich ograniczenia) mogą wystąpić w dowolnym momencie cyklu projektowania:

• Projekt — upewnij się, że projekt nie umożliwia osobom atakującym łatwego uzyskania nieautoryzowanego dostępu do obciążenia, jego danych ani innych zasobów biznesowych w organizacji.
• Kod — upewnij się, że pisanie (i ponowne używanie) kodu nie zezwala osobom atakującym na łatwe przejęcie kontroli nad aplikacją w celu wykonywania nieautoryzowanych akcji, które szkodzą klientom, pracownikom, systemom, danym lub innym zasobom biznesowym. Deweloperzy powinni również pracować w bezpiecznym środowisku, które nie zezwala osobom atakującym na przejęcie kontroli bez ich wiedzy.
• Kompilowanie i wdrażanie — upewnij się, że procesy ciągłej integracji i ciągłego wdrażania (CI/CD) nie zezwalają nieautoryzowanym użytkownikom na zmianę kodu i zezwalają osobom atakującym na naruszenie go.
• Uruchom — upewnij się, że środowisko z uruchomionym kodem (chmura, serwery, urządzenia przenośne, inne) jest zgodne z najlepszymi rozwiązaniami w zakresie zabezpieczeń dla osób, procesów i technologii, aby uniknąć naruszenia i nadużywania obciążenia przez osoby atakujące. Ten proces obejmuje wdrożenie dobrze znanych najlepszych rozwiązań, konfiguracji punktów odniesienia zabezpieczeń i nie tylko.
• Architektura zerowego zaufania i ład — wszystkie te etapy powinny być zgodne z zasadami Zero Trust, aby założyć naruszenie (zakładać naruszenie), jawnie zweryfikować zaufanie i przyznać najmniejsze uprawnienia wymagane dla każdego konta użytkownika, tożsamości komputera/usługi i składnika aplikacji.

Co to jest DevSecOps?

Innowacje technologiczne są często opracowywane w kontekście szybkiego, chudego i elastycznego podejścia programistycznego, które łączy rozwój i operacje w procesie DevOps i integruje zabezpieczenia z tym procesem, ma kluczowe znaczenie dla ograniczenia ryzyka związanego z procesem innowacji, rozwojem organizacji i istniejącymi aktywami w organizacji. Integrowanie zabezpieczeń z procesem powoduje utworzenie procesu DevSecOps .

Zabezpieczanie według projektu i przesuwanie w lewo

Ponieważ organizacje wdrażają metodykę DevOps i inne metodologie szybkiej innowacji, bezpieczeństwo musi być wątkiem tkanym w całej organizacji i jej procesach programistycznych. Integracja zabezpieczeń pod koniec procesu jest kosztowna i trudna do naprawienia.

Przenieś zabezpieczenia w lewo na osi czasu, aby zintegrować je z przewidywaniem, projektowaniem, implementacją i działaniem usług i produktów. W miarę przechodzenia zespołów programistycznych do metodyki DevOps i wdrażania technologii w chmurze bezpieczeństwo musi być częścią tej transformacji.

W modelu kaskadowym bezpieczeństwo było tradycyjnie bramą jakości po zakończeniu opracowywania.

Metodyka DevOps rozszerzyła tradycyjny model programowania (osoby, proces i technologię), aby uwzględnić zespoły operacyjne. Ta zmiana zmniejszyła tarcie, które wynikało z oddzielenia zespołów programistycznych i operacyjnych. Podobnie metodyka DevSecOps rozszerza metodyki DevOps, aby zmniejszyć tarcie od oddzielnych lub różnych zespołów ds. zabezpieczeń.

DevSecOps to integracja zabezpieczeń na każdym etapie cyklu życia metodyki DevOps od pomysłu poprzez przewidywanie, projektowanie architektury, iteracyjne tworzenie aplikacji i operacje. Zespoły muszą być jednocześnie dostosowane do celów szybkości innowacji, niezawodności i odporności zabezpieczeń. Z wzajemnym zrozumieniem i wzajemnym szacunkiem dla siebie potrzeb, zespoły pracują najpierw nad najważniejszymi kwestiami, niezależnie od źródła.

Metodologia organizacji przewodnika Cloud Adoption Framework zawiera dalszy kontekst struktur DevSecOps w organizacji. Aby uzyskać więcej informacji, zobacz Omówienie zabezpieczeń aplikacji i funkcji DevSecOps.

Dlaczego metodyka DevSecOps?

Metodyka DevOps zapewnia elastyczność, a metodyka DevSecOps zapewnia bezpieczną elastyczność.

Prawie każda organizacja na świecie chce opracowywać oprogramowanie, aby uzyskać przewagę konkurencyjną dzięki innowacjom. Zabezpieczanie procesu DevOps ma kluczowe znaczenie dla sukcesu organizacji. Osoby atakujące zauważyły tę zmianę w aplikacjach niestandardowych i coraz częściej atakują niestandardowe aplikacje podczas ataków. Te nowe aplikacje są często bogatymi źródłami cennej własności intelektualnej, które zawierają cenne nowe pomysły, które nie są jeszcze towarem na rynku.

Ochrona tej innowacji wymaga, aby organizacje sprostały potencjalnym słabościom zabezpieczeń i atakom zarówno w procesie programowania, jak i infrastrukturze obsługującej aplikacje. Takie podejście należy zastosować zarówno do zasobu chmurowego, jak i lokalnego.

Osoby atakujące mogą osiągnąć swoje cele, wykorzystując słabe strony procesu programowania, podstawowej infrastruktury dla obciążeń lub obu tych elementów:

• Ataki programistyczne wykorzystujące słabe punkty w procesie projektowania i tworzenia aplikacji. Na przykład osoby atakujące mogą znaleźć kod, który nie weryfikuje danych wejściowych (zezwalających na typowe ataki, takie jak wstrzyknięcie kodu SQL) lub może znaleźć, że aplikacja używa słabego szyfrowania (lub braku szyfrowania) do komunikacji. Ponadto osoby atakujące mogą wszczepić tylne drzwi w kodzie, dzięki czemu mogą wrócić później do zasobów w środowisku lub w środowisku klienta.
• Ataki infrastruktury, które zagrażają elementom punktu końcowego i infrastruktury hostowanym przez proces programowania przy użyciu standardowych ataków. Osoby atakujące mogą również przeprowadzić wieloestowy atak, który używa skradzionych poświadczeń lub złośliwego oprogramowania w celu uzyskania dostępu do infrastruktury programistycznej z innych części środowiska.

Ponadto ryzyko ataków łańcucha dostaw oprogramowania sprawia, że kluczowe znaczenie ma zintegrowanie zabezpieczeń w procesie dla obu tych systemów:

• Ochrona organizacji przed złośliwym kodem i lukami w zabezpieczeniach w łańcuchu dostaw kodu źródłowego
• Ochrona klientów przed wszelkimi problemami z zabezpieczeniami w aplikacjach i systemach, co może spowodować uszkodzenie reputacji, odpowiedzialność lub inne negatywne skutki biznesowe w organizacji

Podróż DevSecOps

Większość organizacji uważa, że metodyka DevOps lub DevSecOps dla dowolnego obciążenia lub aplikacji jest w rzeczywistości procesem dwufazowym. Pomysły najpierw inkubują w bezpiecznej przestrzeni i są później wydawane do produkcji jako minimalny opłacalny produkt (MVP). Są następnie iteracyjne i stale aktualizowane.

Ten diagram przedstawia cykl życia tego rodzaju podejścia do fabryki innowacji:

Bezpieczne innowacje to zintegrowane podejście do obu tych faz:

• Inkubacja pomysłu, w którym jest zbudowana, zweryfikowana i gotowa do początkowego użycia produkcyjnego. Ta faza rozpoczyna się od nowego pomysłu i kończy się, gdy pierwsza wersja produkcyjna spełnia kryteria minimalnego opłacalnego produktu (MVP) dla:
  • Programowanie: Funkcjonalność spełnia minimalne wymagania biznesowe
  • Zabezpieczenia: Możliwości spełniają wymagania dotyczące zgodności z przepisami, zabezpieczeń i bezpieczeństwa do użytku produkcyjnego
  • Operacje: Funkcjonalność spełnia minimalne wymagania dotyczące jakości, wydajności i możliwości obsługi jako systemu produkcyjnego
• DevOps: ta faza to ciągły iteracyjny proces tworzenia aplikacji lub obciążenia, który umożliwia ciągłe innowacje i ulepszenia

Imperatyw przywództwa: Mieszanie kultur

Spełnienie tych trzech wymagań wymaga scalenia tych trzech kultur, aby zapewnić, że wszyscy członkowie zespołu cenią wszystkie typy wymagań i współpracują ze sobą w celu osiągnięcia wspólnych celów.

Integrowanie tych kultur i celów ze sobą w prawdziwe podejście DevSecOps może być trudne, ale warto zainwestować. Wiele organizacji doświadcza wysokiego poziomu problemów związanych z programowaniem, operacjami IT i zespołami ds. zabezpieczeń, którzy pracują niezależnie, tworząc problemy z:

• Powolne dostarczanie wartości i niska elastyczność
• Problemy z jakością i wydajnością
• Problemy z zabezpieczeniami

Chociaż posiadanie kilku problemów jest normalne i oczekiwane w przypadku nowego programowania, konflikty między zespołami często znacznie zwiększają liczbę i ważność tych problemów. Konflikty występują, często dlatego, że jedna lub dwie drużyny mają przewagę polityczną i wielokrotnie przesłaniają wymagania innych zespołów. Z czasem zaniedbywane problemy rosną w objętości i powagi. Pozostawiono nierozwiązane, ta dynamika może pogorszyć się w przypadku metodyki DevOps, ponieważ szybkość podejmowania decyzji zwiększa się w celu zaspokojenia szybkiej ewolucji potrzeb biznesowych i preferencji klientów.

Rozwiązanie tych problemów wymaga utworzenia kultury udostępnionej, która ceni wymagania deweloperskie, sec i ops obsługiwane przez kierownictwo. Takie podejście umożliwi zespołom lepsze współdziałanie i pomoże rozwiązać najpilniejsze problemy w danym przebiegu, niezależnie od tego, czy poprawiają bezpieczeństwo, stabilność operacyjną, czy też dodają krytyczne funkcje biznesowe.

Techniki przywództwa

Te kluczowe techniki mogą pomóc liderom w tworzeniu kultury wspólnej:

1. Nikt nie wygrywa wszystkich argumentów: Liderzy nie muszą zagwarantować, że żaden pojedynczy sposób myślenia nie dominuje we wszystkich decyzjach, które mogą powodować nierównowagę, która negatywnie wpływa na firmę.
2. Spodziewaj się ciągłego ulepszania, a nie doskonałości: Liderzy powinni określić oczekiwania dotyczące ciągłego ulepszania i ciągłego uczenia się. Tworzenie pomyślnego programu DevSecOps nie dzieje się z dnia na dzień. Jest to ciągła podróż z przyrostowym postępem.
3. Świętuj zarówno wspólne zainteresowania, jak i unikatowe indywidualne wartości: Upewnij się, że zespoły mogą zobaczyć, że pracują nad wspólnymi wynikami, a każda osoba zapewnia coś, czego inni nie mogą. Wszystkie typy wymagań dotyczą tworzenia i ochrony tej samej wartości biznesowej. Programowanie próbuje utworzyć nową wartość, podczas gdy elementy operacyjne i zabezpieczenia próbują chronić i zachować te wartości przed różnymi scenariuszami ryzyka. Liderzy na wszystkich poziomach w całej organizacji powinni komunikować się z tą wspólnością i jak ważne jest spełnienie wszystkich typów wymagań zarówno w przypadku natychmiastowego, jak i długoterminowego sukcesu.
4. Opracowywanie wspólnego zrozumienia: wszyscy członkowie zespołu powinni mieć podstawową wiedzę na temat następujących elementów:
   • Pilność biznesowa: Zespół powinien mieć jasny obraz przychodów w grę. Ten widok powinien obejmować bieżący przychód (jeśli usługa jest w trybie offline) oraz potencjalne przyszłe przychody, na które ma wpływ opóźnienie dostarczania aplikacji i funkcji. Ten widok powinien być oparty bezpośrednio na sygnałach zainteresowanych stron.
   • Prawdopodobne zagrożenia i zagrożenia: na podstawie danych wejściowych zespołu analizy zagrożeń, jeśli istnieje, zespół powinien ustalić poczucie prawdopodobnych zagrożeń, z którymi będzie borykać się portfolio aplikacji.
   • Wymagania dotyczące dostępności: Zespół powinien mieć wspólne poczucie wymagań operacyjnych, takich jak wymagany czas pracy, oczekiwany okres istnienia aplikacji oraz wymagania dotyczące rozwiązywania problemów i konserwacji, na przykład stosowanie poprawek podczas pracy w trybie online.
5. Demonstracja i modelowanie żądanego zachowania: Liderzy powinni publicznie modelować zachowanie, które chcą od swoich zespołów. Na przykład pokaż pokorę, skoncentruj się na uczeniu się i wartości innych dyscyplinach. Innym przykładem jest omówienie wartości aplikacji i aplikacji wysokiej jakości oraz menedżerów ds. zabezpieczeń o wartości szybkiej innowacji i wydajności aplikacji.
6. Monitorowanie poziomu problemów z zabezpieczeniami: Zabezpieczenia naturalnie tworzą tarcie, które spowalnia procesy. Ważne jest, aby liderzy monitorowali poziom i rodzaj tarć generowanych przez zabezpieczenia:
   • Zdrowe tarcie: Podobnie jak ćwiczenia sprawiają, że mięśnie są silniejsze, integrując odpowiedni poziom tarcia bezpieczeństwa w procesie DevOps wzmacnia aplikację, zmuszając krytyczne myślenie we właściwym czasie. Jeśli zespoły uczą się i wykorzystują te informacje, aby poprawić bezpieczeństwo, na przykład biorąc pod uwagę, dlaczego i jak osoba atakująca może spróbować naruszyć bezpieczeństwo aplikacji, oraz znajdować i naprawiać ważne błędy zabezpieczeń, to są one na dobrej drodze.
   • Tarcie w złej kondycji: Uważaj na tarcie, które utrudnia większą wartość niż chroni. To tarcie często występuje, gdy błędy zabezpieczeń generowane przez narzędzia mają wysoki współczynnik wyników fałszywie dodatnich lub fałszywych alarmów albo gdy wysiłek zabezpieczeń w celu naprawienia czegoś przekracza potencjalny wpływ ataku.
7. Integracja zabezpieczeń w planowaniu budżetu: upewnij się, że budżet zabezpieczeń jest przydzielany proporcjonalnie do innych inwestycji w zabezpieczenia. Ta koncepcja jest analogiczna do fizycznego wydarzenia, takiego jak koncert, w którym budżet wydarzenia obejmuje bezpieczeństwo fizyczne jako normę. Niektóre organizacje przydzielają 10 procent całkowitego kosztu zabezpieczeń jako ogólną regułę, aby zapewnić spójne stosowanie najlepszych rozwiązań w zakresie zabezpieczeń.
8. Ustanów wspólne cele: Upewnij się, że metryki wydajności i powodzenia dla obciążeń aplikacji odzwierciedlają cele związane z programowaniem, zabezpieczeniami i operacjami.

Uwaga

W idealnym przypadku zespoły te powinny wspólnie tworzyć te wspólne cele, aby zmaksymalizować zakup, zarówno dla całej organizacji, jak i dla konkretnego projektu lub aplikacji.

Identyfikowanie MVP metodyki DevSecOps

Podczas przejścia od pomysłu do środowiska produkcyjnego kluczowe jest zapewnienie, że funkcja spełnia minimalne wymagania lub minimalny produkt opłacalny (MVP) dla każdego typu wymagania:

• Deweloperzy (deweloperzy) koncentrują się na reprezentowaniu potrzeb biznesowych w celu szybkiego dostarczania możliwości, które spełniają oczekiwania użytkowników, klientów i liderów biznesowych. Zidentyfikuj minimalne wymagania, aby zapewnić, że funkcja pomaga organizacji odnieść sukces.
• Bezpieczeństwo (s) koncentruje się na spełnianiu zobowiązań w zakresie zgodności i obronie przed osobami atakującymi, które nieustannie szukają nielegalnego zysku z zasobów organizacji. Zidentyfikuj minimalne wymagania, aby spełnić wymagania dotyczące zgodności z przepisami, utrzymać stan zabezpieczeń i zapewnić szybkie wykrywanie i reagowanie na aktywny atak operacji zabezpieczeń.
• Operacje (ops) koncentrują się na wydajności, jakości i wydajności, zapewniając, że obciążenie może nadal dostarczać wartość w dłuższej perspektywie. Zidentyfikuj minimalne wymagania, aby zapewnić, że obciążenie może działać i być obsługiwane bez konieczności wprowadzania ogromnych zmian architektury lub projektu w najbliższej przyszłości.

Definicje MVP mogą się zmieniać wraz z upływem czasu i z różnymi typami obciążeń, ponieważ zespół uczy się razem z własnego środowiska i z innych organizacji.

Integracja zabezpieczeń natywnie w procesie

Wymagania dotyczące zabezpieczeń muszą być skoncentrowane na natywnej integracji z istniejącym procesem i narzędziami. Na przykład:

• Działania projektowe, takie jak modelowanie zagrożeń, powinny być zintegrowane z fazą projektowania
• Narzędzia do skanowania zabezpieczeń powinny być zintegrowane z systemami ciągłej integracji i ciągłego dostarczania (CI/CD), takimi jak Azure DevOps, GitHub i Jenkins
• Problemy z zabezpieczeniami należy zgłaszać przy użyciu tych samych systemów i procesów śledzenia usterek, na przykład schematu priorytetyzacji, co inne błędy.

Sposób, w jaki zabezpieczenia są zintegrowane z procesem, należy stale ulepszać, gdy zespoły uczą się i przetwarzają procesy. Przeglądy zabezpieczeń i oceny ryzyka powinny zapewnić, że środki zaradcze są zintegrowane z procesami kompleksowego programowania, ostateczną usługą produkcyjną i podstawową infrastrukturą.

Aby uzyskać więcej informacji na temat metodyki DevSecOps, zobacz DevSecOps technical controls (Kontrolki techniczne metodyki DevSecOps).

Porady dotyczące poruszania się po podróży

Transformacja wymaga budowania w kierunku tego idealnego stanu przyrostowo w podróży. Wiele organizacji musi poruszać się po złożoności i wyzwaniach w tej podróży. W tej sekcji opisano niektóre typowe, z którymi borykają się organizacje.

• Zmiany edukacji i kultury są krytycznymi wczesnymi krokami: idziesz na wojnę z armią, którą masz. Zespół, który często musi rozwijać nowe umiejętności i wdrażać nowe perspektywy, aby zrozumieć inne części modelu DevSecOps. Ta zmiana edukacji i kultury zajmuje trochę czasu, skupić się, sponsorować kierownictwo i regularnie śledzić, aby pomóc osobom w pełni zrozumieć i zobaczyć wartość zmiany. Zmiana kultur i umiejętności drastycznie może czasami wykorzystać profesjonalną tożsamość osób, tworząc potencjał silnego oporu. Ważne jest, aby zrozumieć i wyrazić, dlaczego, co i jak zmienia się dla każdej osoby i ich sytuacji.
• Zmiana zajmuje trochę czasu: możesz przejść tak szybko, jak twój zespół może dostosować się do implikacji wykonywania rzeczy w nowy sposób. Zespoły zawsze będą musiały wykonywać swoje istniejące zadania podczas transformacji. Ważne jest, aby dokładnie określić priorytety najważniejszych elementów i zarządzać oczekiwaniami dotyczącymi tego, jak szybka może się zdarzyć ta zmiana. Skupienie się na przeszukiwaniu, spacerze, strategii uruchamiania, gdzie najważniejsze i podstawowe elementy będą dobrze służyć twojej organizacji.
• Ograniczone zasoby: Organizacje, które zwykle napotykają na wczesnym etapie, polega na znalezieniu talentów i umiejętności zarówno w zakresie zabezpieczeń, jak i tworzenia aplikacji. W miarę jak organizacje zaczynają pracować wydajniej, mogą znaleźć ukryte talenty, takie jak deweloperzy z myślą o bezpieczeństwie lub specjaliści ds. zabezpieczeń z doświadczeniem deweloperów.
• Zmiana charakteru aplikacji, kodu i infrastruktury: definicja techniczna i kompozycja aplikacji zmienia się zasadniczo wraz z wprowadzeniem technologii, takich jak bezserwerowe, usługi w chmurze, interfejsy API w chmurze i aplikacje bez kodu, takie jak Power Apps. Ta zmiana zmienia praktyki programistyczne, zabezpieczenia aplikacji, a nawet umożliwia tworzenie aplikacji przez niedeveloperów.

Uwaga

Niektóre implementacje łączą operacje i obowiązki związane z zabezpieczeniami w rolę inżyniera niezawodności lokacji (SRE ).

Chociaż łączenie tych obowiązków w jedną rolę może być idealnym stanem końcowym dla niektórych organizacji, często jest to skrajna zmiana w porównaniu z obecnymi praktykami przedsiębiorstwa, kulturą, narzędziami i zestawami umiejętności.

Nawet jeśli model SRE jest przeznaczony dla Ciebie, zalecamy rozpoczęcie od osadzania zabezpieczeń w metodyce DevOps przy użyciu praktycznych szybkich zwycięstw i przyrostowych postępów opisanych w tych wskazówkach, aby upewnić się, że uzyskujesz dobry zwrot z inwestycji (ROI) i spełniasz natychmiastowe potrzeby. Spowoduje to przyrostowe dodanie obowiązków dotyczących zabezpieczeń do Twoich pracowników operacyjnych i programistycznych, co przybliża ludzi do stanu końcowego SRE (jeśli organizacja planuje później wdrożyć ten model).

Następne kroki

Zapoznaj się z kontrolkami technicznymi devSecOps, aby uzyskać bardziej szczegółowe wskazówki dotyczące metodyki DevSecOps.

Aby uzyskać informacje na temat sposobu integrowania zabezpieczeń zaawansowanych usługi GitHub z potokami ciągłej integracji i ciągłego dostarczania (CI/CD), zobacz About GitHub advanced security (Informacje o zaawansowanych zabezpieczeniach usługi GitHub).

Aby uzyskać więcej informacji i narzędzi dotyczących sposobu implementacji metodyki DevSecOps przez organizację IT firmy Microsoft, zobacz Bezpieczny zestaw narzędzi DevOps.