Podręcznik użytkownika oprogramowania AXIS Security Development Model

Oprogramowanie modelu rozwojowego zabezpieczeń AXIS

Wstęp

Cele ASDM
Model rozwoju zabezpieczeń firmy Axis (ASDM) to struktura definiująca proces i narzędzia używane przez firmę Axis do tworzenia oprogramowania z wbudowanymi zabezpieczeniami w całym cyklu życia, od momentu powstania do wycofania z eksploatacji.

Głównymi celami kierującymi wysiłkami ASDM są:

• Spraw, aby bezpieczeństwo oprogramowania stało się integralną częścią działań firmy Axis związanych z rozwojem oprogramowania.
• Zmniejsz ryzyko biznesowe związane z bezpieczeństwem dla klientów Axi.
• Meet increasing awareness of security considerations by customers and partners.
• Stwórz potencjał redukcji kosztów dzięki wczesnemu wykrywaniu i rozwiązywaniu problemów
  Zakres ASDM to oprogramowanie Axis zawarte w produktach i rozwiązaniach Axis. Właścicielem i opiekunem ASDM jest Software Security Group (SSG).

Słowniczek

Koniec ASDMview

ASDM obejmuje kilka działań rozmieszczonych w głównych fazach rozwoju. Działania związane z bezpieczeństwem są zbiorczo określane jako ASDM.

The SSG is responsible for governing the ASDM and evolving the toolbox over time. There is an ASDM roadmap and a rollout plan for implementing new activities and increasing ASDM maturity across the development organization. Both the roadmap and rollout plan are owned by the SSG, but the responsibility for actual implementation in practice (i.e., performing activities related to development phases) is delegated to the R&D teams.

Grupa ds. Bezpieczeństwa oprogramowania (SSG)

SSG jest główną wewnętrzną jednostką kontaktową wobec organizacji zajmujących się rozwojem w kwestiach związanych z bezpieczeństwem. Składa się z liderów bezpieczeństwa i innych osób posiadających specjalistyczną wiedzę na temat bezpieczeństwa w obszarach rozwoju, takich jak wymagania, projektowanie, wdrażanie, weryfikacja,
a także międzyfunkcjonalne procesy DevOps.
SSG jest odpowiedzialna za rozwój i utrzymanie ASDM w zakresie bezpiecznych praktyk programistycznych i świadomości bezpieczeństwa w organizacji deweloperskiej.

Satelity
Satelity to członkowie organizacji programistycznych, którzy spędzają część swojego czasu na pracy nad aspektami bezpieczeństwa oprogramowania. Powody posiadania satelitów są następujące:

• Skaluj ASDM bez budowania dużej centralnej SSG
• Zapewnij wsparcie ASDM blisko zespołów programistycznych
• Ułatwianie dzielenia się wiedzą, np. najlepszymi praktykami
  Satelita będzie pomagał we wdrażaniu nowych działań i utrzymaniu ASDM w podzbiorze zespołów programistycznych.

Wdrożenie działania ASDM
Wdrażanie działań ASDM do zespołu programistów odbywa się w następujący sposóbtagproces redakcyjny:

1. Zespół zostaje wprowadzony w nową działalność poprzez szkolenie dostosowane do określonej roli.
2. SSG współpracuje z zespołem w celu wykonania czynności, np. oceny ryzyka lub modelowania zagrożeń, dla wybranych części systemu(ów) zarządzanego przez zespół.
3. Dalsze działania związane z integracją zestawu narzędzi w codziennej pracy zostaną przekazane zespołowi i satelicie, gdy będą oni gotowi do samodzielnej pracy bez bezpośredniego zaangażowania SSG. Na tym etapie pracą kieruje kierownik zespołu poprzez status ASDM.
   Wdrożenie jest powtarzane, gdy dostępne są nowe wersje ASDM ze zmodyfikowanymi i/lub dodanymi działaniami. Ilość czasu spędzonego przez SSG z zespołem w dużym stopniu zależy od aktywności i złożoności kodu. Kluczowym czynnikiem pomyślnego przekazania zespołu zespołowi jest istnienie wbudowanego satelity, który może kontynuować z zespołem dalszą pracę ASDM. SSG steruje uczeniem się i przydzielaniem satelity równolegle z wdrażaniem działań.
   Poniższy rysunek podsumowuje metodologię wdrożenia.

   

Definicja SSG „gotowego” w przypadku przekazania to:

• Przeprowadzono szkolenie dotyczące konkretnej roli
• Satelita przydzielony
• Zespół jest gotowy do wykonania czynności ASDM
• Ustanowiono cykliczne spotkania dotyczące statusu ASDM
  SSG korzysta z informacji przekazywanych przez zespoły w celu tworzenia raportów o stanie dla kadry kierowniczej wyższego szczebla.

Pozostała działalność SSG
Równolegle z działaniami wdrożeniowymi SSG prowadzi szersze działania szkoleniowe w zakresie świadomości bezpieczeństwa, skierowane np. do nowych pracowników i wyższej kadry kierowniczej. Ponadto SSG utrzymuje mapę cieplną zabezpieczeń rozwiązań Axis do celów oceny ryzyka ogólnego/architektonicznego. Na podstawie mapy cieplnej przeprowadzane są proaktywne działania związane z analizą bezpieczeństwa poszczególnych modułów.

Role i obowiązki
Jak pokazano w poniższej tabeli, istnieje kilka kluczowych podmiotów i ról, które są częścią programu ASDM. Poniższa tabela podsumowuje role i obowiązki w odniesieniu do ASDM.

Zarządzanie ASDM

System zarządzania składa się z następujących części:

• Mapa termiczna ryzyka systemowego pomagająca w ustaleniu priorytetów działań ASDM
• Plan wdrożenia i status, aby skupić się na działaniach szkoleniowych
• Plan rozwoju zestawu narzędzi
• Status mierzący stopień integracji działań ASDM w organizacji

System ASDM jest zatem wspierany zarówno z perspektywy taktycznej/operacyjnej, jak i strategicznej/wykonawczej.
Wytyczne wykonawcze po prawej stronie rysunku koncentrują się na tym, jak rozwijać organizację w celu uzyskania optymalnej efektywności zgodnie z celami biznesowymi Axis. Ważnym wkładem w to jest raportowanie stanu ASDM wykonywane przez SSG do Grupy Sterującej ds. Firmware, CTO i Kierownictwa Produktu.

Struktura statusu ASDM

Struktura statusu ASDM ma dwie perspektywy: jedną skoncentrowaną na zespole, naśladującą strukturę naszego zespołu i działu, oraz drugą skoncentrowaną na rozwiązaniach, skupiającą się na rozwiązaniach, które wprowadzamy na rynek.
Poniższy rysunek ilustruje strukturę statusu ASDM.

Stan drużyny
Status zespołu zawiera samoocenę dojrzałości ASDM dokonaną przez zespół, metryki związane z jego działaniami w zakresie analizy bezpieczeństwa, a także agregację stanu bezpieczeństwa komponentów, za które jest on odpowiedzialny.

Axis definiuje dojrzałość ASDM jako wersję ASDM, z której aktualnie korzysta zespół. Ponieważ ASDM ewoluuje, zdefiniowaliśmy wersjonowanie ASDM, w którym każda wersja ASDM zawiera unikalny zestaw działań. Na przykładample, nasza pierwsza wersja ASDM koncentruje się na modelowaniu zagrożeń.
Firma Axis zdefiniowała następujące wersje ASDM:

Przekazanie zespołowi własności wersji ASDM, z której korzysta, oznacza, że ​​to przełożony jest odpowiedzialny za przyjęcie nowych wersji ASDM. Zatem zamiast konfiguracji, w której SSG forsuje centralny plan wdrożenia ASDM, jest on teraz oparty na ściąganiu i kontrolowany przez menedżerów.

Stan komponentu

• Mamy szeroką definicję komponentu, ponieważ musimy uwzględnić wszelkiego rodzaju jednostki architektoniczne, począwszy od demonów Linuksa na platformie, poprzez oprogramowanie serwerowe, aż po usługi w chmurze (mikro).
• Każdy zespół musi samodzielnie wybrać poziom abstrakcji, który sprawdza się w jego środowisku i architekturze. Zasadą jest, że zespoły powinny unikać wymyślania nowego poziomu abstrakcji i zachować to, czego już używają w swojej codziennej pracy.
• Pomysł jest taki, że każdy zespół powinien mieć jasne określenie view wszystkich komponentów wysokiego ryzyka, które obejmują zarówno nowe, jak i starsze komponenty. Motywacja zwiększonego zainteresowania starszymi komponentami jest powiązana z naszą zdolnością do sprawdzania stanu bezpieczeństwa rozwiązań. W przypadku rozwiązania chcemy mieć wgląd w stan bezpieczeństwa wszystkich części rozwiązania, zarówno nowych, jak i starych.
• W praktyce oznacza to, że każdy zespół musi sprawdzić swój zapas komponentów i dokonać oceny ryzyka.
• Pierwszą rzeczą, którą musimy wiedzieć, jest to, czy komponent przeszedł analizę bezpieczeństwa. Jeśli tak nie jest, tak naprawdę nie wiemy nic o jakości bezpieczeństwa komponentu.

Nazywamy to ubezpieczeniem majątku i zdefiniowaliśmy następujące poziomy ubezpieczenia:

Metryki, których używamy do określenia jakości zabezpieczeń komponentu, opierają się na elementach pracy związanych z bezpieczeństwem w rejestrze zadań, które są powiązane z komponentem. Mogą to być środki zaradcze, które nie zostały wdrożone, przypadki testowe, które nie zostały wykonane lub błędy bezpieczeństwa, które nie zostały usunięte.

Stan rozwiązania

Stan rozwiązania agreguje stan zabezpieczeń zestawu komponentów tworzących rozwiązanie.
Pierwszą częścią statusu rozwiązania jest pokrycie analizą komponentów. Pomaga to właścicielom rozwiązań w zrozumieniu, czy stan zabezpieczeń rozwiązania jest znany, czy nie. Z jednej strony pomaga to zidentyfikować martwe punkty. Pozostała część stanu rozwiązania zawiera metryki, które odzwierciedlają jakość bezpieczeństwa rozwiązania. Robimy to, przyglądając się elementom pracy związanym z bezpieczeństwem, które są powiązane z komponentami rozwiązania. Ważnym aspektem stanu bezpieczeństwa jest pasek błędów zdefiniowany przez właścicieli rozwiązania. Właściciele rozwiązań muszą zdefiniować odpowiedni poziom bezpieczeństwa dla swojego rozwiązania. Na przykładample, oznacza to, że po wypuszczeniu na rynek rozwiązanie nie powinno mieć otwartych żadnych zaległych elementów pracy o znaczeniu krytycznym lub o wysokiej istotności.

Działalność ASDM

Ocena ryzyka
Głównym celem oceny ryzyka jest odfiltrowanie działań programistycznych, które będą również wymagały pracy w zespole nad bezpieczeństwem.
Ocenę ryzyka przeprowadza się poprzez ocenę, czy nowy produkt lub dodana/zmodyfikowana funkcja w istniejących produktach zwiększa narażenie na ryzyko. Należy pamiętać, że obejmuje to również aspekty prywatności danych i wymogi dotyczące zgodności. ByłyampInne zmiany mające wpływ na ryzyko to nowe interfejsy API, zmiany w wymaganiach autoryzacyjnych, nowe oprogramowanie pośrednie itp.

Prywatność danych
Zaufanie to kluczowy obszar zainteresowania Axis, dlatego ważne jest przestrzeganie najlepszych praktyk podczas pracy z prywatnymi danymi gromadzonymi przez nasze produkty, rozwiązania i usługi.
Zakres działań Axis związanych z prywatnością danych jest zdefiniowany w taki sposób, że możemy:

• Wypełnij zobowiązania prawne
• Wypełniaj zobowiązania umowne
• Pomóż klientom wypełnić swoje obowiązki

Działalność związaną z ochroną danych osobowych dzielimy na dwa poddziałania:

• Ocena prywatności danych
  • Dokonano podczas oceny ryzyka
  • Określa, czy potrzebna jest analiza prywatności danych
•  Analiza prywatności danych
  • Wykonywane, jeśli ma to zastosowanie, podczas modelowania zagrożeń
  • Identyfikuje dane osobowe i zagrożenia dla danych osobowych
  • Definiuje wymagania dotyczące prywatności

Modelowanie zagrożeń
Zanim zaczniemy identyfikować zagrożenia, musimy zdecydować o zakresie modelu zagrożeń. Sposobem określenia zakresu jest opisanie napastników, których musimy wziąć pod uwagę. Takie podejście pozwoli nam również zidentyfikować powierzchnie ataku wysokiego poziomu, które musimy uwzględnić w analizie.

• Podczas określania zakresu zagrożeń skupiamy się na wyszukiwaniu i kategoryzowaniu atakujących, z którymi chcemy się uporać, przy użyciu ogólnego opisu systemu. Najlepiej, jeśli opis jest wykonywany przy użyciu diagramu przepływu danych (DFD), ponieważ ułatwia to powiązanie bardziej szczegółowych opisów przypadków użycia, które są wykorzystywane podczas tworzenia modelu zagrożenia.
• Nie oznacza to, że należy wziąć pod uwagę wszystkich zidentyfikowanych przez nas atakujących, oznacza to po prostu, że jednoznacznie i konsekwentnie określamy napastników, do których zajmiemy się w modelu zagrożenia. Zasadniczo zatem napastnicy, których wybierzemy do rozważenia, określą poziom bezpieczeństwa systemu, który oceniamy.
  Należy pamiętać, że nasz opis atakującego nie uwzględnia jego możliwości ani motywacji. Wybraliśmy to podejście, aby maksymalnie uprościć i usprawnić modelowanie zagrożeń.

  

Modelowanie zagrożeń składa się z trzech etapów, które można powtarzać według uznania zespołu:

1. Opisz system za pomocą zestawu DFD
2. Użyj DFD, aby zidentyfikować zagrożenia i opisać je w stylu przypadku nadużycia
3. 3. Zdefiniuj środki zaradcze i weryfikację zagrożeń
   Wynikiem modelowania zagrożeń jest model zagrożeń zawierający zagrożenia i środki zaradcze z określonym priorytetem. Prace rozwojowe wymagane w celu rozwiązania środków zaradczych zarządzane są poprzez tworzenie zgłoszeń Jira zarówno do wdrożenia, jak i weryfikacji środka zaradczego.

   

Analiza kodu statycznego
W ASDM zespoły mogą korzystać ze statycznej analizy kodu na trzy sposoby:

• Przepływ pracy programisty: programiści analizują kod, nad którym pracują
• Przepływ pracy w Gerrit: programiści otrzymują opinie w Gerrit
• Starszy przepływ pracy: zespoły analizują starsze komponenty wysokiego ryzyka

  

Skanowanie podatności
Regularne skanowanie pod kątem luk w zabezpieczeniach umożliwia zespołom programistycznym identyfikowanie i łatanie luk w oprogramowaniu przed udostępnieniem produktów publicznie, zmniejszając ryzyko klientów podczas wdrażania produktu lub usługi. Skanowanie jest przeprowadzane przed wydaniem każdej wersji sprzętu, oprogramowania) lub zgodnie z bieżącym harmonogramem (usługi) przy użyciu zarówno pakietów typu open source, jak i komercyjnych pakietów do skanowania pod kątem luk w zabezpieczeniach. Wyniki skanów służą do generowania zgłoszeń na platformie śledzenia zgłoszeń Jira. Bilety otrzymują specjalną ofertę tag być identyfikowalne przez zespoły programistów jako pochodzące ze skanowania pod kątem luk w zabezpieczeniach i że należy im nadać podwyższony priorytet. Wszystkie skany podatności i zgłoszenia Jira są przechowywane centralnie w celu śledzenia i audytu. Krytyczne luki powinny zostać usunięte przed wydaniem lub w specjalnej wersji serwisowej z innymi, niekrytycznymi lukami,
śledzone i rozwiązywane zgodnie z cyklem wydawania oprogramowania sprzętowego lub oprogramowania. kor więcej informacji na temat sposobu oceniania i zarządzania lukami w zabezpieczeniach można znaleźć w części Zarządzanie lukami w zabezpieczeniach na stronie 12

Zewnętrzne testy penetracyjne
W wybranych przypadkach zewnętrzne testy penetracyjne przeprowadzane są na sprzęcie lub oprogramowaniu firmy Axis. Głównym celem przeprowadzania tych testów jest zapewnienie wglądu i pewności co do bezpieczeństwa platformy w określonym momencie i w określonym zakresie. Jednym z naszych głównych celów w ASDM jest przejrzystość, dlatego zachęcamy naszych klientów do przeprowadzania zewnętrznych testów penetracyjnych naszych produktów i chętnie współpracujemy przy definiowaniu odpowiednich parametrów do testów, a także dyskusjach na temat interpretacji wyników.

Zarządzanie podatnością
Od 2021 r. Axis jest zarejestrowanym organem nazewniczym CVE (CNA), w związku z czym może publikować standardowe raporty CVE w bazie danych MITRE w celu wykorzystania przez zewnętrzne skanery podatności na ataki i inne narzędzia. Tablica ds. luk w zabezpieczeniach (VB) to wewnętrzny punkt kontaktowy Axis w sprawie luk w zabezpieczeniach odkrytych przez zewnętrznych badaczy. Zgłaszanie
wykryte luki i późniejsze plany naprawcze są przekazywane za pośrednictwem produkt-bezpieczeństwo@axis.com adres e-mail.
Głównym obowiązkiem komisji ds. podatności jest analiza i ustalanie priorytetów zgłaszanych luk w zabezpieczeniach z perspektywy biznesowej w oparciu o

• Klasyfikacja techniczna podana przez SSG
• Potencjalne ryzyko dla użytkowników końcowych w środowisku, w którym działa urządzenie Axis
• Dostępność kompensujących mechanizmów kontroli bezpieczeństwa, alternatywnego ograniczania ryzyka bez łatania)

VB rejestruje numer CVE i współpracuje ze zgłaszającym w celu przypisania luce wyniku CVSS. VB zapewnia także komunikację zewnętrzną z partnerami i klientami za pośrednictwem usługi powiadamiania o bezpieczeństwie firmy Axis, komunikatów prasowych i artykułów prasowych.

Model rozwoju bezpieczeństwa Axis © Axis Communications AB, 2022