Co należy umieścić w polityce bezpieczeństwa informacji dla tworzenia oprogramowania?
Polityka bezpieczeństwa informacji dla tworzenia oprogramowania to dokument, w którym określasz, w jaki sposób twoja organizacja postępuje z bezpieczeństwem informacji, systemów i kodu. W przypadku firmy zajmującej się tworzeniem oprogramowania chodzi o dwie rzeczy jednocześnie: bezpieczeństwo tego, co budujesz, i bezpieczeństwo środowiska, w którym to budujesz. Obie kwestie należą do tego samego dokumentu, chociaż są to merytorycznie różne zagadnienia.
W praktyce oznacza to, że polityka zwykle obejmuje zakres (które systemy i które projekty rozwojowe podlegają) odpowiedzialność (kto decyduje, kto zarządza, kto kontroluje), sposób, w jaki reguluje się dostęp do kodu źródłowego i środowisk programistycznych, jak są wykrywane i usuwane luki w bezpieczeństwie własnego kodu, jak postępuje się ze środowiskami testowymi i środowiskami produkcyjnymi, jak rejestruje się incydenty oraz jak polityka sama w sobie jest utrzymywana i weryfikowana. Lista kontrolna odbiorcy często pyta dokładnie o tego rodzaju dokumenty jako dowód, a nie o techniczny opis twojego kodu źródłowego.
Dwie warstwy: produkt i łańcuch oprogramowania
Pierwsza warstwa dotyczy produktu: oprogramowania dostarczanego klientom. Obejmuje ona opis sposobu postępowania z lukami w bezpieczeństwie odkrytymi po dostarczeniu, jak aktualizacje i poprawki trafiają do klientów oraz kto w organizacji odpowiada za śledzenie zgłoszeń dotyczących problemów bezpieczeństwa produktu.
Druga warstwa dotyczy łańcucha oprogramowania: środowiska, w którym pracuje twój zespół. To środowisko kontroli wersji, potok budowania i testowania oraz separacja między środowiskami testowymi i produkcyjnymi. Chodzi tu o pytania takie jak: kto ma dostęp do kodu źródłowego, jak są kontrolowane zmiany przed ich wdrożeniem, oraz jak dostęp jest odbierany, gdy ktoś opuszcza zespół. Obie warstwy mogą znajdować się w tym samym dokumencie, ale często są opisywane osobno, ponieważ ryzyko i ich właściciele różnią się.
Dlaczego odbiorca pyta o to
Organizacje, które Same podlegają obowiązkowi opieki, są obowiązane do oceny ryzyka swoich dostawców. Firma zajmująca się tworzeniem oprogramowania dla takiej organizacji otrzymuje w ten sposób pytania, które nie wynikają z własnego obowiązku, ale z łańcucha dostaw. Polityka bezpieczeństwa informacji jest wtedy często pierwszym dokumentem, który jest żądany, ponieważ pokazuje w jednym dokumencie, jak strukturalnie podejście do bezpieczeństwa jest opracowywane. Jeśli go brakuje, musisz to wyjaśnić osobno w każdym pytaniu z listy kontrolnej, co zajmuje więcej czasu i jest mniej przekonujące niż istniejący dokument.
To, czy twoja organizacja sama podlega obowiązkowi opieki, czy podlega łańcuchowi dostaw, czy żadnemu z nich, nie jest widoczne na pierwszy rzut oka. w kilku pytaniach widać, gdzie stoi Twoja organizacja zapewnia wstępne wskazanie, z wyjaśnieniem przyczyny.
Jak ta polityka ma się do poszczególnych środków
Polityka bezpieczeństwa informacji nie stanowi samodzielnego dokumentu. Opisuje w zarysie, jak postępujesz z bezpieczeństwem, podczas gdy poszczególne środki — kontrola dostępu, kopie zapasowe, rejestracja incydentów, ocena dostawców — to konkretna realizacja tego. Kto pisze politykę bez wprowadzenia w porządek podstawowych środków, ma dokument, który nie odpowiada praktyce. Odwrotnie też jest trudne: poszczególne środki bez polityki nadrzędnej wyglądają na rozproszeni dla tych, którzy o to pytają. przegląd wszystkich tematów w każdej sytuacji pokazuje, jak te elementy ze sobą współzależą.
Co w praktyce często brakuje
W wielu pierwszych wersjach takiej polityki brakuje wyraźnego właściciela dla każdego składnika: kto jest odpowiedzialny za utrzymywanie aktualnej polityki dostępu, kto za politykę łatania. Często brakuje również ustalonej daty oceny, przez co polityka sprzed dwóch lat nadal jest przedstawiana jako aktualna, podczas gdy linia rozwojowa tymczasem się zmieniła. I trzecia kwestia, która często znika: wyraźne powiązanie między polityką a dowodami pokazującymi, że jest ona faktycznie wdrażana, takimi jak dzienniki praw dostępu lub przegląd zastosowanych poprawek.
Oceń własną sytuację
To, które dokładnie elementy są oczekiwane, zależy od roli Twojej organizacji w łańcuchu dostaw oraz od tego, o co pyta konkretny odbiorca. Ten artykuł opisuje typową strukturę, a nie obowiązkowy szablon, a sam tekst ustawy nie określa stałego podziału. Aby ocenić Twoją specyficzną sytuację, właściwym partnerem jest prawnik lub właściwy organ nadzoru; najczęściej zadawane pytania dotyczące tego typu dokumentów zawiera dodatkowy przegląd tego, o co często się pyta.
Chcesz zobaczyć, jak taka polityka, razem z leżącymi u podstaw środkami i dowodami, jest utrzymywana w bieżącym dossier zamiast jako oddzielny dokument? jak secria.eu buduje i utrzymuje informacje to pokazuje. W przeciwnym razie zacznij od bezpłatnego sprawdzenia NIS2 lub przejrzyj bazę wiedzy, aby zobaczyć, które tematy są istotne dla Twojej organizacji.