Secure by Design według CISA: praktyczne wdrożenie

Secure by Design oznacza, że bezpieczeństwo jest właściwością produktu i odpowiedzialnością jego producenta, a nie dodatkowym zadaniem przerzuconym na klienta. CISA opisuje trzy główne zasady: odpowiedzialność producenta za rezultaty, radykalną przejrzystość oraz przywództwo od najwyższego szczebla.

To podejście zmienia decyzje produktowe. Funkcja, która domyślnie zwiększa ekspozycję, musi uzasadnić ryzyko, a podstawowe zabezpieczenia nie powinny być płatnym dodatkiem.

Bezpieczne ustawienia domyślne

Nowe konto powinno mieć MFA dostępne bez dopłaty, minimalne uprawnienia i bezpieczną konfigurację sesji. Interfejs administracyjny nie może być publiczny bez wyraźnej decyzji. Logowanie zdarzeń bezpieczeństwa powinno działać od pierwszego uruchomienia.

Użytkownik może zmienić ustawienie, ale produkt powinien jasno pokazać konsekwencje. Domyślna konfiguracja nie może zależeć od przeczytania wielostronicowej instrukcji hardeningu.

Projektuj przeciw całym klasom błędów

Priorytetem są kontrole usuwające klasy podatności: parametryzowane zapytania, centralna autoryzacja, języki memory-safe, bezpieczne biblioteki kryptograficzne i odporne mechanizmy aktualizacji. Lista zakazanych funkcji jest słabsza niż API, które utrudnia ich niebezpieczne użycie.

Model zagrożeń wykonuj przed zamrożeniem architektury. Zidentyfikuj granice zaufania, dane, role i scenariusze nadużyć. Wyniki zamień w wymagania oraz testy w procesie DevSecOps.

Przejrzystość bez marketingu

Publikuj informacje o podatnościach, przyczynach źródłowych i działaniach systemowych. Nie ograniczaj analizy do pojedynczej poprawki. Jeśli jeden wzorzec występuje w kilku komponentach, wyszukaj go w całej rodzinie produktów.

Utrzymuj SBOM, politykę wsparcia, bezpieczny kanał aktualizacji i program zgłaszania podatności. Klient musi wiedzieć, jak długo produkt otrzymuje poprawki i gdzie zgłosić problem.

Mierniki dla zarządu

Nie wystarczy liczba zamkniętych ticketów. Mierz:

udział klientów korzystających z phishing-resistant MFA;
czas od zgłoszenia do ochrony wszystkich wersji;
liczbę domyślnie publicznych funkcji;
powtarzalność tych samych klas błędów;
pokrycie krytycznych przepływów testami bezpieczeństwa;
odsetek produktów ze wspieranym mechanizmem automatycznej aktualizacji.

Te wskaźniki pokazują wynik dla użytkownika, a nie aktywność zespołu.

Bramka wydania oparta na ryzyku

Secure by Design nie oznacza, że każda poprawka ma zatrzymać wydanie. Zespół potrzebuje jawnych kryteriów: które scenariusze nadużyć są niedopuszczalne, kto akceptuje ryzyko i na jak długo oraz jakie dowody muszą powstać przed wdrożeniem. Dla funkcji uwierzytelniania mogą to być testy obejścia MFA, rotacji sesji i odzyskiwania konta; dla importu plików — walidacja typu, limitów i izolacji przetwarzania.

Wyjątek powinien mieć właściciela, termin wygaśnięcia i plan usunięcia. Bez tego tymczasowe odstępstwo staje się trwałą architekturą. W krytycznych przepływach bramka może wymagać modelu zagrożeń, przeglądu zmian, testów automatycznych i niezależnego testu penetracyjnego. Zakres kontroli dobiera się do ryzyka, nie do liczby linii kodu.

Bezpieczeństwo po sprzedaży produktu

Odpowiedzialność producenta nie kończy się w dniu wydania. Potrzebny jest wykaz wspieranych wersji, proces przyjmowania zgłoszeń, możliwość szybkiego przygotowania aktualizacji i sposób poinformowania klientów. Telemetria bezpieczeństwa powinna pomagać wykryć nadużycie bez gromadzenia danych ponad potrzebę. Mechanizm aktualizacji musi weryfikować pochodzenie pakietu i odpornie obsługiwać przerwanie procesu.

Po podatności przeprowadź analizę przyczyny źródłowej na trzech poziomach: błąd w kodzie, luka w procesie oraz decyzja produktowa, która umożliwiła ekspozycję. Następnie wyszukaj ten sam wzorzec w pozostałych komponentach i dodaj kontrolę zapobiegającą regresji. Samo policzenie CVE nie mówi, czy produkt staje się bezpieczniejszy.

Relacja z SSDF i testami

NIST SSDF porządkuje praktyki bezpiecznego wytwarzania w czterech grupach: przygotowanie organizacji, ochrona oprogramowania, produkcja dobrze zabezpieczonego produktu i reakcja na podatności. To dobre rusztowanie procesu, ale nie zastępuje decyzji o domyślnych ustawieniach produktu. Test penetracyjny dostarcza dowodów o konkretnym wydaniu; Secure by Design wymaga dodatkowo zmiany mechanizmów, które wygenerowały problem.

Wymagania bezpieczeństwa zapisuj jako sprawdzalne rezultaty. „System jest bezpieczny” nie jest testowalne. „Użytkownik bez roli finansowej nie może odczytać ani zmienić faktury innego działu, również przez bezpośrednie wywołanie API” daje się zweryfikować w testach jednostkowych, integracyjnych i ręcznych.

Plan wdrożenia

Wyznacz sponsora z uprawnieniami produktowymi.
Zapisz zasady bezpiecznych ustawień domyślnych.
Zmapuj najczęstsze klasy podatności i ich przyczyny.
Dodaj wymagania do decyzji architektonicznych.
Zapewnij podstawowe funkcje bezpieczeństwa bez dopłaty.
Publikuj politykę wsparcia i disclosure.
Mierz rezultaty oraz usuwaj wzorce systemowo.

Secure by Design działa tylko wtedy, gdy bezpieczeństwo wpływa na roadmap, budżet i kryteria wydania. Deklaracja bez zmiany domyślnej konfiguracji produktu nie chroni klienta.

Źródła: CISA — Secure by Design, CISA — Shifting the Balance of Cybersecurity Risk, NIST Secure Software Development Framework.