8.28 Bezpieczne kodowanie

Rodzaj kontroli: Informacja
Właściwości bezpieczeństwa: Prewencyjne, Poufność, Integralność, Dostępność
Koncepcje cyberbezpieczeństwa: Ochrona, Bezpieczeństwo aplikacji, Bezpieczeństwo systemów i sieci
Obszary operacyjne: Ochrona

Kontrola

Zasady bezpiecznego kodowania powinny być stosowane podczas rozwoju oprogramowania.

Cel

Zapewnienie, że oprogramowanie jest pisane w sposób bezpieczny, co zmniejsza liczbę potencjalnych podatności związanych z bezpieczeństwem informacji w oprogramowaniu.

Wytyczne

Ogólne

Organizacja powinna ustanowić procesy w całej organizacji w celu zapewnienia dobrego zarządzania bezpiecznym kodowaniem. Należy ustalić minimalną bezpieczną bazę, która powinna być stosowana. Dodatkowo, procesy te powinny obejmować komponenty oprogramowania pochodzące od dostawców zewnętrznych i oprogramowanie open source.

Organizacja powinna monitorować zagrożenia w realnym świecie oraz aktualne porady i informacje na temat podatności oprogramowania, aby kierować zasadami bezpiecznego kodowania organizacji przez ciągłe doskonalenie i naukę. Może to pomóc w zapewnieniu skutecznych praktyk bezpiecznego kodowania, które radzą sobie z szybko zmieniającym się krajobrazem zagrożeń.

Planowanie i przed kodowaniem

Zasady bezpiecznego kodowania powinny być stosowane zarówno w przypadku nowych rozwoju, jak i w scenariuszach ponownego użycia. Zasady te powinny być stosowane zarówno w działalności wewnętrznej organizacji, jak i w przypadku produktów i usług dostarczanych przez organizację innym podmiotom. Planowanie i wymogi przed kodowaniem powinny obejmować:
a) specyficzne oczekiwania organizacji i zatwierdzone zasady bezpiecznego kodowania do stosowania zarówno przy rozwoju wewnętrznym, jak i zleceniu kodowania;
b) powszechne i historyczne praktyki kodowania oraz defekty, które prowadzą do podatności na zagrożenia związane z bezpieczeństwem informacji;
c) konfigurację narzędzi deweloperskich, takich jak zintegrowane środowiska programistyczne (IDE), aby pomóc w wymuszeniu tworzenia bezpiecznego kodu;
d) stosowanie wskazówek wydanych przez dostawców narzędzi programistycznych i środowisk wykonawczych, jeśli to stosowne;
e) utrzymanie i używanie zaktualizowanych narzędzi deweloperskich (np. kompilatory);
f) kwalifikacje programistów w zakresie pisania bezpiecznego kodu;
g) bezpieczny projekt i architektura, w tym modelowanie zagrożeń;
h) standardy bezpiecznego kodowania i, w razie potrzeby, obowiązkowe ich stosowanie;
i) korzystanie z kontrolowanych środowisk do rozwoju.

Podczas kodowania

W trakcie kodowania należy wziąć pod uwagę:
a) bezpieczne techniki kodowania specyficzne dla używanych języków programowania i technik;
b) stosowanie bezpiecznych technik programowania, takich jak programowanie w parach, refaktoryzacja, przegląd kodu, iteracje bezpieczeństwa i rozwój sterowany testami;
c) stosowanie strukturalnych technik programowania;
d) dokumentowanie kodu i usuwanie defektów programistycznych, które mogą pozwolić na wykorzystanie podatności związanych z bezpieczeństwem;
e) zabronienie stosowania niebezpiecznych technik projektowych (np. użycie hardcoded haseł, niezatwierdzonych próbek kodu i nieautoryzowanych usług webowych).

Testowanie powinno być przeprowadzone zarówno w trakcie, jak i po zakończeniu rozwoju (patrz 8.29). Procesy statycznego testowania bezpieczeństwa aplikacji (SAST) mogą identyfikować podatności bezpieczeństwa w oprogramowaniu.

Przed wprowadzeniem oprogramowania do eksploatacji należy ocenić:
a) powierzchnię ataku i zasadę najmniejszych uprawnień;
b) przeprowadzenie analizy najczęstszych błędów programistycznych i udokumentowanie, że zostały one złagodzone.

Przegląd i utrzymanie

Po wdrożeniu kodu operacyjnego:
a) aktualizacje powinny być bezpiecznie pakowane i wdrażane;
b) zgłoszone podatności bezpieczeństwa informacji powinny być obsługiwane (patrz 8.8);
c) błędy i podejrzane ataki powinny być logowane, a logi regularnie przeglądane w celu dostosowania kodu, jeśli to konieczne;
d) kod źródłowy powinien być chroniony przed nieautoryzowanym dostępem i manipulacjami (np. przez użycie narzędzi do zarządzania konfiguracją, które zazwyczaj zapewniają funkcje takie jak kontrola dostępu i zarządzanie wersjami).

Jeśli używa się zewnętrznych narzędzi i bibliotek, organizacja powinna rozważyć:
a) zapewnienie zarządzania zewnętrznymi bibliotekami (np. przez utrzymanie inwentarza używanych bibliotek i ich wersji) i regularne aktualizowanie ich w ramach cykli wydania;
b) wybór, autoryzację i ponowne użycie dobrze zweryfikowanych komponentów, szczególnie komponentów uwierzytelniania i kryptograficznych;
c) licencję, bezpieczeństwo i historię zewnętrznych komponentów;
d) zapewnienie, że oprogramowanie jest utrzymywalne, śledzone i pochodzi z wiarygodnych źródeł;
e) zapewnienie długoterminowej dostępności zasobów i artefaktów deweloperskich.

Jeśli pakiet oprogramowania musi być zmodyfikowany, należy wziąć pod uwagę:
a) ryzyko związane z kontrolami wbudowanymi i procesami integralności;
b) czy należy uzyskać zgodę od dostawcy;
c) możliwość uzyskania wymaganych zmian od dostawcy jako standardowe aktualizacje oprogramowania;
d) wpływ, jeśli organizacja stanie się odpowiedzialna za przyszłe utrzymanie oprogramowania w wyniku zmian;
e) zgodność z innym oprogramowaniem w użyciu.

Inne informacje

Zasadą przewodnią jest zapewnienie, że kod o znaczeniu bezpieczeństwa jest wywoływany w razie potrzeby i jest odporny na manipulacje. Programy instalowane z kodu binarnego skompilowanego również mają te właściwości, ale tylko dla danych przechowywanych w aplikacji. W przypadku języków interpretowanych koncepcja ta działa tylko wtedy, gdy kod jest wykonywany na serwerze, do którego użytkownicy i procesy nie mają dostępu, a dane są przechowywane w podobnie chronionych bazach danych. Na przykład, kod interpretowany może być uruchamiany na usłudze chmurowej, gdzie dostęp do samego kodu wymaga uprawnień administratora. Takie uprawnienia administracyjne powinny być chronione przez mechanizmy bezpieczeństwa, takie jak zasady administracji na żądanie i silne uwierzytelnianie. Jeśli właściciel aplikacji może uzyskać dostęp do skryptów przez bezpośredni dostęp zdalny do serwera, to teoretycznie może to zrobić także atakujący. Należy skonfigurować serwery WWW, aby zapobiec przeglądaniu katalogów w takich przypadkach.

Aplikacje internetowe są podatne na różnorodne podatności, które są wprowadzane przez błędy projektowe i kodowanie, takie jak ataki wstrzykiwania do baz danych i cross-site scripting. W tych atakach zapytania mogą zostać zmanipulowane w celu wykorzystania funkcji serwera WWW.