Bezpieczeństwo organizacyjne i operacyjne

Podstawą dobrych praktyk dotyczących zabezpieczeń jest organizacja.

Tworzenie zespołu ds. bezpieczeństwa i prywatności

Utwórz specjalny zespół ds. bezpieczeństwa i prywatności oraz wyznacz lidera tej organizacji.

  • Utwórz zespół ds. bezpieczeństwa.
    • Zadbaj o to, aby co najmniej 1 pracownik był odpowiedzialny za bezpieczeństwo, prywatność i reakcję na incydenty.
    • Określ misję i zakres działania zespołu.
    • Opracuj schemat organizacyjny i opis stanowiska dla: menedżera ds. bezpieczeństwa, inżyniera ds. bezpieczeństwa, menedżera ds. incydentów.
    • zatrudnić pracowników lub zewnętrznych wykonawców, aby pełnili te role.
  • Określ cykl życia procesu tworzenia oprogramowania pod kątem bezpieczeństwa (SDL). Twoja SDL powinna obejmować te obszary:
    • Wymagania dotyczące bezpieczeństwa produktów.
    • analiza ryzyka i modelowanie zagrożeń.
    • Statyczną i dynamiczną analizę aplikacji i kodu.
    • Ostateczne procesy sprawdzania bezpieczeństwa produktów.
    • Reagowanie na incydenty.
  • Oceń ryzyko organizacyjne. Utwórz ocenę ryzyka i opracuj plany, które pomogą je wyeliminować lub ograniczyć.

Tworzenie procesu weryfikacji

Ocenianie luk w dotychczasowych procesach weryfikacji i zatwierdzania wersji wewnętrznych.

  • Zidentyfikuj luki w bieżącym procesie weryfikacji kompilacji, które mogą prowadzić do wprowadzenia aplikacji potencjalnie niebezpiecznej (PHA) do kompilacji.
  • Upewnij się, że masz proces sprawdzania i zatwierdzania kodu, nawet w przypadku poprawek do AOSP tworzonych wewnętrznie.
  • Zwiększ integralność kompilacji, wdrażając mechanizmy kontroli w tych obszarach:
    • Śledź zmiany. śledzić inżynierów oprogramowania i prowadzić dzienniki zmian;
    • Oceń ryzyko. Oceniaj uprawnienia używane przez aplikację. Wymagaj ręcznego sprawdzania zmian w kodzie.
    • Monitorowanie. Ocenianie zmian wprowadzonych w kodzie uprzywilejowanym.

Śledzenie zmian w kodzie źródłowym

Monitoruj przypadkowe modyfikacje kodu źródłowego lub aplikacji / binaries / SDK innych firm.

  • Oceń partnerstwo. Aby ocenić ryzyko związane z współpracą z partnerem technicznym, wykonaj te czynności:
    • Określ kryteria oceny ryzyka związanego z współpracy z konkretnym dostawcą.
    • Utwórz formularz, w którym poprosisz dostawcę o opis sposobu rozwiązywania incydentów oraz zarządzania bezpieczeństwem i prywatnością.
    • okresowo weryfikować ich roszczenia;
  • Śledź zmiany. Zapisuj, które firmy i pracownicy modyfikują kod źródłowy, oraz przeprowadzaj okresowe kontrole, aby mieć pewność, że wprowadzane są tylko odpowiednie zmiany.
  • Prowadź dokumentację. Zapisz, które firmy dodają do Twojej kompilacji pliki binarne innych firm, a także jakie funkcje pełnią te aplikacje i jakie dane zbierają.
  • Zaplanuj aktualizacje. Dopilnuj, aby dostawcy byli zobowiązani do dostarczania aktualizacji oprogramowania przez cały okres użytkowania produktu. Nieprzewidziane luki w zabezpieczeniach mogą wymagać pomocy dostawców.

Weryfikacja integralności i pochodzenia kodu źródłowego

Sprawdzanie i weryfikowanie kodu źródłowego dostarczonego przez producenta oryginalnego urządzenia (ODM), aktualizacji bezprzewodowej (OTA) lub operatora.

  • Zarządzaj certyfikatami podpisywania.
    • przechowywać klucze w sprzętowym module zabezpieczeń (HSM) lub zabezpieczonej usłudze w chmurze (nie udostępniaj ich);
    • Zapewnij kontrolę i audyt dostępu do certyfikatów podpisywania.
    • Wymagaj, aby wszystkie podpisywanie kodu odbywało się w systemie kompilacji.
    • Unieważnianie utraconych kluczy.
    • Generuj klucze zgodnie ze sprawdzonymi metodami.
  • Analizuje nowy kod. Testuj nowo dodany kod za pomocą narzędzi do analizy kodu, aby sprawdzić, czy nie zawiera on nowych luk w zabezpieczeniach. Dodatkowo należy przeanalizować ogólną funkcjonalność, aby wykryć nowe luki w zabezpieczeniach.
  • Sprawdź przed opublikowaniem. Przed wdrożeniem kodu źródłowego i aplikacji innych firm na ścieżkę produkcyjną sprawdź, czy nie zawierają one luk w zabezpieczeniach. Na przykład:
    • Wymagaj, aby aplikacje używały bezpiecznej komunikacji.
    • Stosuj zasadę jak najmniejszych uprawnień i przyznaj minimalny zestaw uprawnień potrzebnych do działania aplikacji.
    • Zadbaj o to, aby dane były przechowywane i przesyłane przez bezpieczne kanały.
    • Zadbaj o aktualność zależności usługi.
    • Zastosuj poprawki zabezpieczeń do pakietów SDK i bibliotek open source.

Reagowanie na incydenty

Android wierzy w potencjał silnej społeczności zajmującej się bezpieczeństwem, która pomaga w identyfikowaniu problemów. Należy utworzyć i opublikować sposób, w jaki osoby z zewnątrz mogą się z Tobą skontaktować w sprawie problemów z bezpieczeństwem związanym z danym urządzeniem.

  • Nawiązanie kontaktu. Utwórz adres e-mail, na przykład security@your-company.com, lub stronę internetową z jasnymi instrukcjami zgłaszania potencjalnych problemów z zabezpieczeniami związanych z Twoim produktem (przykład).
  • Utwórz program wykrywania luk w zabezpieczeniach (VRP). Zachęcaj zewnętrznych badaczy zabezpieczeń do przesyłania raportów o lukach w zabezpieczeniach, które wpływają na Twoje produkty, oferując nagrody pieniężne za prawidłowe zgłoszenia (przykład). Zalecamy nagradzanie badaczy nagrodami na poziomie konkurencyjnym w branży, takimi jak 5000 USD za luki o poważnym stopniu zagrożenia oraz 2500 USD za luki o wysokim stopniu zagrożenia.
  • przesyłać zmiany do upstream. Jeśli dowiesz się o problemie z bezpieczeństwem, który dotyczy platformy Android lub urządzeń od wielu producentów, skontaktuj się z zespołem ds. bezpieczeństwa Androida, przesyłając raport o błędach związanych z bezpieczeństwem.
  • promować dobre praktyki dotyczące bezpieczeństwa, Proaktywnie oceniaj praktyki bezpieczeństwa dostawców sprzętu i oprogramowania, którzy dostarczają usługi, komponenty lub kod dla Twoich urządzeń. wymagać od dostawców utrzymania dobrej postawy w zakresie bezpieczeństwa;