Utrzymuj oprogramowanie przez cały okres jego użytkowania

Wyznacz właściciela utrzymania usługi

Użyteczne oprogramowanie zmienia się po pierwszym wydaniu. Zależności otrzymują poprawki. Środowiska runtime tracą wsparcie. Certyfikaty wygasają. Reguły biznesowe się zmieniają. Dostęp przyznany podczas konfiguracji może pozostać aktywny dłużej, niż planowano.

Prowadź inwentaryzację usług, właścicieli, wdrożonych wersji, zależności i terminów wsparcia. Uwzględnij prace planowe oraz wynikające z nowych ustaleń. Zarezerwuj czas na oba rodzaje. Backlog utrzymaniowy bez właściciela nie chroni usługi.

Oddziel utrzymanie od natychmiastowej reakcji na incydent. Ujawnione dane uwierzytelniające lub oznaki aktywnego włamania mogą wymagać ograniczenia skutków przed końcem zwykłego cyklu wytwarzania. Kieruj takie przypadki do procesu reagowania na incydenty bezpieczeństwa.

Ustal priorytet na podstawie rzeczywistej ekspozycji

Poziom zagrożenia opisuje możliwe konsekwencje. Priorytet zależy także od wykorzystania podatności, dostępności podatnej funkcji, danych, istniejących zabezpieczeń i kosztu opóźnienia. Usługa wewnętrzna o małym ruchu nadal może przechowywać ważne dane uwierzytelniające.

Katalog CISA Known Exploited Vulnerabilities gromadzi podatności, dla których istnieją dowody wykorzystania. Uwzględniaj go przy ustalaniu priorytetów. Brak wpisu nie dowodzi, że podatność jest bezpieczna. Katalog CISA.

Rozważ poniższe fikcyjne problemy. Terminy należą do przykładowej organizacji; nie są powszechnie obowiązującymi limitami.

Nie przekształcaj automatycznie każdego problemu w dużą aktualizację. Wybierz wspieraną poprawkę, sprawdź zgodność i przetestuj istotne zachowanie. Dla tymczasowych zabezpieczeń zapisz właściciela i warunek wygaśnięcia.

Prześledź poprawkę aż do produkcji

Zachowaj powiązania między kolejnymi etapami: wykrycie, decyzja, zmiana, review, wdrożenie i weryfikacja. Zapisz identyfikator artefaktu rzeczywiście używanego w produkcji. Po zmianie ponownie przeskanuj odpowiedni artefakt lub środowisko.

W fikcyjnym przykładzie podatnego pakietu PDF zespół merguje aktualizację o 10:00. O 11:00 produkcja nadal używa wczorajszego obrazu. Poprawka w repozytorium jest gotowa. Usuwanie podatności w produkcji pozostaje nieukończone.

Po wdrożeniu sprawdź wersję pakietu i generowanie PDF. Skan podatności nie potwierdzi, że eksport nadal działa. Test funkcjonalny nie potwierdzi usunięcia podatnego komponentu.

NIST SSDF obejmuje ciągłe wykrywanie podatności i reagowanie na nie. Stosuj te praktyki w całym cyklu życia, także w oprogramowaniu, które rzadko otrzymuje nowe funkcje. NIST SSDF.

Automatyzuj z widocznymi ograniczeniami

Taiga Maintaining skanuje powiązane repozytoria i może przekształcać wyniki w inicjatywy naprawcze. Sprawdź ostatni udany skan, podatną wersję i wynikającą z niego zmianę. Skan repozytorium nie ustala, czy podatna funkcja jest dostępna w produkcji. Maintaining.

Automatyzacja może ograniczyć powtarzalną pracę, ale usługa nadal potrzebuje właściciela wdrożeń i weryfikacji. Jasno określ decyzje o wydaniu, dostęp awaryjny i terminy wygaśnięcia wyjątków.

Utrzymanie obejmuje także wycofanie usługi. Usuwaj nieużywane ścieżki, dane uwierzytelniające, integracje i infrastrukturę w kontrolowanym procesie. Przed usunięciem sprawdź wymagania retencji i zależne usługi. Wyłącz działającą usługę i przypisz pozostałe obowiązki retencyjne lub audytowe.

Następna lekcja szczegółowo opisuje ciągłe skanowanie podatności i ich usuwanie.