Bezpieczeństwo innowacji

Innowacje są częścią życia organizacji w epoce cyfrowej i muszą być zarówno włączone, jak i chronione. Bezpieczeństwo innowacji chroni procesy i dane innowacji przed cyberatakami. Innowacje w epoce cyfrowej mają postać tworzenia aplikacji przy użyciu metody DevOps lub DevSecOps , aby szybko wprowadzać innowacje bez oczekiwania na tradycyjny harmonogram wysyłki kaskadowej, który może potrwać miesiące lub lata między wydaniami.

Tworzenie nowych możliwości i aplikacji wymaga pomyślnego spełnienia trzech różnych typów wymagań:

• Programowanie biznesowe (Dev): Aplikacja musi spełniać potrzeby biznesowe i użytkownika, które często szybko ewoluują.
• Zabezpieczenia (Sec): Aplikacja musi być odporna na ataki przed szybko zmieniającymi się osobami atakującymi i korzystać z innowacji w zabezpieczeniach zabezpieczeń.
• Operacje IT (Ops): 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 ds. zabezpieczeń muszą współpracować, aby zwiększyć tę zmianę. Aby uzyskać więcej informacji, zobacz imperatyw przywództwa: łączenie kultur.

Obejrzyj poniższy film wideo, aby dowiedzieć się więcej o metodzie DevSecOps na potrzeby bezpiecznych i szybkich innowacji.

Co to jest DevSecOps?

Innowacje technologiczne są często opracowywane w kontekście szybkiego i elastycznego podejścia programistycznego, które łączy programowanie i operacje razem w procesie DevOps . Dowiedzieliśmy się, że zintegrowanie zabezpieczeń z tym procesem ma kluczowe znaczenie w celu ograniczenia ryzyka związanego z procesem innowacji, rozwojem organizacji i istniejącymi elementami zawartości w organizacji. Integrowanie zabezpieczeń w procesie powoduje utworzenie procesu DevSecOps .

Zabezpieczanie przy użyciu projektu i przesunięcia w lewo

Ponieważ organizacje przyjmują metodykę DevOps i inne metodologie szybkiej innowacji, bezpieczeństwo musi być wątkiem tkanym w całej taśmie organizacji i jej procesów programistycznych. Integrowanie zabezpieczeń pod koniec procesu jest kosztowne i trudne 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 zabezpieczenia muszą być częścią tej transformacji.

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

Metodyka DevOps rozszerzyła tradycyjny model programowania (osoby, procesy i technologie), aby uwzględnić zespoły operacyjne. Ta zmiana zmniejszyła tarcie, które wynikało z oddzielenia zespołów programistycznych i operacyjnych. Podobnie usługa 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, dzięki przewidywaniu, projektowaniu architektury, tworzeniu i operacjach iteracyjnych aplikacji. Zespoły muszą być jednocześnie dostosowane do celów szybkości innowacji, niezawodności i odporności zabezpieczeń. Przy wzajemnym zrozumieniu i wzajemnym szacunku dla siebie potrzeb zespoły będą najpierw pracować nad najważniejszymi kwestiami, niezależnie od źródła.

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

Dlaczego devSecOps?

Metodyka DevOps zapewnia elastyczność, usługa DevSecOps zapewnia bezpieczną elastyczność.

Prawie każda organizacja na świecie wygląda na rozwój oprogramowania, 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ą aplikacje niestandardowe 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 rozwiązywały potencjalne słabości zabezpieczeń i ataki zarówno w procesie programowania, jak i infrastrukturze hostujących aplikacje. Takie podejście jest stosowane zarówno do chmury, jak i środowiska lokalnego.

Osoby atakujące mogą wykorzystać słabe strony w:

• Proces programowania: Osoby atakujące mogą znaleźć słabe strony procesu projektowania aplikacji, na przykład przy użyciu słabego lub braku szyfrowania komunikacji. Osoby atakujące mogą znaleźć słabość w implementacji projektu, na przykład kod nie weryfikuje danych wejściowych i umożliwia typowe ataki, takie jak wstrzyknięcie kodu SQL. Ponadto osoby atakujące mogą wszczepić tylne drzwi w kodzie, co pozwala im wrócić później do wykorzystania w środowisku użytkownika lub w środowisku klienta.
• Infrastruktura IT: Osoby atakujące mogą naruszyć bezpieczeństwo elementów punktu końcowego i infrastruktury, które są hostowane w procesie 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ńcuchów dostaw oprogramowania sprawia, że kluczowe znaczenie ma zintegrowanie zabezpieczeń z procesem obu tych procesów:
• Ochrona organizacji: Z złośliwego kodu i luk w zabezpieczeniach w łańcuchu dostaw kodu źródłowego
• Ochrona klientów: Z wszelkich problemów z zabezpieczeniami w aplikacjach i systemach, które mogą spowodować uszkodzenie reputacji, odpowiedzialność lub inne negatywne skutki biznesowe na twoją organizację

Podróż devSecOps

Większość organizacji stwierdza, że metodyka DevOps lub DevSecOps dla dowolnego obciążenia lub aplikacji jest w rzeczywistości dwufazowym procesem, w którym pomysły najpierw inkubują się w bezpiecznym miejscu, a następnie wydane w środowisku produkcyjnym i iteracyjnym i stale aktualizowanym.

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

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

• Inkubacja pomysłu , w którym jest tworzony, weryfikowany i gotowy 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:
  • Rozwoju: Funkcjonalność spełnia minimalne wymagania biznesowe
  • Zabezpieczeń: Możliwości spełniają wymagania dotyczące zgodności z przepisami, zabezpieczeń i bezpieczeństwa do użytku produkcyjnego
  • Operacji: 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: Łączenie kultur

Spełnienie tych trzech wymagań wymaga scalenia tych trzech kultur ze sobą w celu zapewnienia, że wszyscy członkowie zespołu cenią wszystkie typy wymagań i współpracują ze sobą w kierunku 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 złej kondycji 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

Mając kilka 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. W miarę upływu czasu zaniedbane problemy rosną w ilości i powagi. Pozostawione nierozwiązane, ta dynamika może pogorszyć się w przypadku metodyki DevOps, ponieważ szybkość podejmowania decyzji zwiększa się, aby sprostać szybkiej ewolucji potrzeb biznesowych i preferencji klientów.

Rozwiązywanie tych problemów wymaga utworzenia wspólnej kultury, która ceni wymagania deweloperskie, sec i ops, które są obsługiwane przez przywództwo. Takie podejście umożliwi zespołom lepszą współpracę i pomoże w rozwiązywaniu najbardziej pilnych problemów w danym przebiegu, niezależnie od tego, czy poprawiają bezpieczeństwo, stabilność operacyjną, czy dodawanie krytycznych funkcji biznesowych.

Techniki przywództwa

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

1. Nikt nie wygrywa wszystkich argumentów: Liderzy muszą zapewnić, ż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łej poprawy, a nie doskonałości: Liderzy powinni stosować oczekiwania dotyczące ciągłego doskonalenia i ciągłego uczenia się. Utworzenie udanego 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 interesy, jak i unikatowe wartości indywidualne: Upewnij się, że zespoły widzą, że pracują nad typowymi 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 dla 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 stawce. Ten widok powinien obejmować bieżący przychód (jeśli usługa jest w trybie offline) oraz potencjalne przyszłe przychody, które będą miały wpływ na opóźnienie dostarczania aplikacji i funkcji. Powinno to być bezpośrednio oparte na sygnałach zainteresowanych stron przywódców.
   • Prawdopodobne zagrożenia i zagrożenia: W oparciu o dane wejściowe zespołu ds. analizy zagrożeń 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 rozwiązywanie problemów i wymagania dotyczące konserwacji, na przykład stosowanie poprawek w trybie online.

5. Zademonstrowanie 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 są menedżerowie deweloperów omawiają wartość zabezpieczeń i wysokiej jakości aplikacji lub menedżerów zabezpieczeń omawiają wartość 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 typ tarć generowanych przez zabezpieczenia:

   • Tarcie w dobrej kondycji: Podobnie jak ćwiczenie sprawia, że mięśnie są silniejsze, integrując odpowiedni poziom tarcia zabezpieczeń w procesie DevOps wzmacnia aplikację, zmuszając krytyczne myślenie w odpowiednim czasie. Jeśli zespoły uczą się i używają tych szkoleń, 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 znaleźć i naprawić ważne usterki zabezpieczeń, to są one na dobrej drodze.
   • Tarcie w złej kondycji: Należy zwrócić uwagę na tarcie, które utrudnia większą wartość niż chroni. Dzieje się tak często, gdy błędy zabezpieczeń generowane przez narzędzia mają wysoki współczynnik fałszywie dodatnich lub fałszywe alarmy lub gdy wysiłek bezpieczeństwa w celu naprawienia czegoś przekracza potencjalny wpływ ataku.

7. Integrowanie zabezpieczeń z planowaniem budżetu: Upewnij się, że budżet na zabezpieczenia jest przydzielany proporcjonalnie do innych inwestycji w zabezpieczenia. Jest to podobne do fizycznego wydarzenia, takiego jak koncert, w którym budżet wydarzenia obejmuje zabezpieczenia fizyczne jako normę. Niektóre organizacje przydzielają 10 procent całkowitego kosztu zabezpieczeń jako ogólną zasadę, 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 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 znaczenie ma zapewnienie, że funkcja spełnia minimalne wymagania lub minimalny opłacalny produkt (MVP) dla każdego typu wymagania:

• Deweloperzy (deweloperzy) koncentrują się na reprezentowaniu potrzeb biznesowych w celu szybkiego dostarczania możliwości spełniających oczekiwania użytkowników, klientów i liderów biznesowych. Zidentyfikuj minimalne wymagania, aby zapewnić, że funkcja pomoże organizacji odnieść sukces.
• Bezpieczeństwo (s) koncentruje się na spełnieniu zobowiązań w zakresie zgodności i obrony przed osobami atakującymi, którzy nieustannie szukają nielegalnych zysków 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 ogromnych zmian architektury lub projektowania w najbliższej przyszłości.

Definicje MVP mogą zmieniać się 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ą skupić się 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 błędów, na przykład schematu priorytetyzacji, co inne usterki.

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

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

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

Transformacja wymaga budowania w kierunku tego idealnego stanu przyrostowo podczas podróży. Wiele organizacji będzie musiało 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 w edukacji i kulturze są krytycznymi wczesnymi krokami:Idziesz na wojnę z armią, którą masz. Zespół, który ma być często potrzebny do opracowania nowych umiejętności i przyjęcia nowych perspektyw, aby zrozumieć inne części modelu DevSecOps. Ta zmiana edukacji i kultury wymaga czasu, skupienia się, sponsorowania wykonawczego i regularnego śledzenia, 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 zmiana dla każdej osoby i ich sytuacji.
• Zmiana zajmuje czas: Możesz poruszać się tak szybko, jak zespół może dostosować się do implikacji robienia 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 tego, co jest najważniejsze i jak szybko może się zdarzyć, aby zarządzać oczekiwaniami dotyczącymi tego, jak szybko może się to zdarzyć. Skupienie się na przeszukiwaniu, spacerze, uruchamianiu strategii, gdzie najważniejsze i podstawowe elementy są najważniejsze, będą dobrze służyć twojej organizacji.
• Ograniczone zasoby: Organizacje, z którymi zwykle borykają się na wczesnym etapie, to znalezienie talentów i umiejętności zarówno w zakresie zabezpieczeń, jak i tworzenia aplikacji. Ponieważ organizacje zaczynają wydajniej współpracować, mogą znaleźć ukryte talenty, takie jak deweloperzy z myślą o bezpieczeństwie lub specjalistów ds. zabezpieczeń z doświadczeniem deweloperów.
• Zmiana charakteru aplikacji, kodu i infrastruktury: Definicja techniczna i kompozycja aplikacji zasadniczo zmienia się 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 deweloperom tworzenie aplikacji.

Uwaga

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

Podczas łączenia 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 bieżącymi praktykami przedsiębiorstwa, kulturą, narzędziami i zestawami umiejętności.

Nawet jeśli celujesz w model SRE, 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 w zakresie zabezpieczeń do personelu ds. operacji i programowania, co przybliża osoby do stanu końcowego procesu 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, w jaki zaawansowane zabezpieczenia usługi GitHub integrują zabezpieczenia 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 implementowania metodyki DevSecOps przez organizację IT firmy Microsoft, zobacz Bezpieczny zestaw narzędzi DevOps.