Żadne przetwarzanie danych i informacji nie może odbywać się bez oprogramowania. Tworzenie oprogramowania koncentruje się przede wszystkim na specyficznym dla danego zadania funkcjonowaniu algorytmów. Jednak obecnie dobrze znany jest fakt, że złe napisanie kodu programu często powoduje również problemy z bezpieczeństwem, takie jak wadliwa kontrola dostępu, wstrzykiwanie kodu SQL, nieprawidłowe zarządzanie sesjami i uwierzytelnianie, cross-site scripting, itp.

Duże znaczenie praktyk bezpiecznego kodowania zostało podkreślone w zaktualizowanych normach bezpieczeństwa informacji ISO/IEC 27002 i ISO/IEC 27001:2022. Jako nowy środek bezpieczeństwa informacji ( kontrola), zasady "Bezpiecznego kodowania" w tworzeniu oprogramowania wchodzą do katalogu środków w załączniku A normy ISO/IEC 27001. Przeczytaj o znaczeniu tego środka dla bezpieczeństwa informacji i co to oznacza dla przyszłych audytów w naszym wpisie na blogu.

Podatności bezpieczeństwa w kodzie

Oprogramowanie systemu operacyjnego, oprogramowanie aplikacyjne czy firmware w systemie wbudowanym to elementarne składniki każdej infrastruktury cyfrowej. Jednak rosnące przyspieszenie i presja terminów w projektach cyfryzacji często prowadzą do zaniedbania imperatywnych aspektów bezpieczeństwa informacji. Wymagania dotyczące rozwoju oprogramowania są zazwyczaj skoncentrowane na funkcjach i podkreślają aspekty konstruktywne, więc destrukcyjne spojrzenie na potencjalne luki bezpieczeństwa jest najczęściej diametralnie różne od rzeczywistych celów rozwoju: wielu programistom po prostu również brakuje uporządkowanego i wyostrzonego spojrzenia na cyberbezpieczeństwo.

W tych warunkach zespoły programistów mają trudności z ciągłym przeglądaniem i konsekwentnym zabezpieczaniem kodowania swojego oprogramowania, czego dowodem jest wiele luk w zabezpieczeniach, które organizacja non-profit MITRE Corporation publikuje co roku na swojej liście CVE (Common Vulnerabilities and Exposures). Regularne łatki bezpieczeństwa nawet znanych producentów oprogramowania są wskaźnikiem syzyfowej pracy nad likwidacją błędów istotnych dla bezpieczeństwa, nie mówiąc już o ich identyfikacji, zanim jeszcze zostaną wprowadzone na rynek.

Kod open source - przypadek szczególny

Podczas kodowania samodzielnie tworzonego oprogramowania programiści chętnie sięgają po biblioteki i moduły open source. Praktyczne zalety są oczywiste: jeśli nie musisz wymyślać koła na nowo, korzystasz z tego zastrzyku technologii, szybszego rozwoju, niższych kosztów rozwoju, większej przejrzystości dzięki otwartemu kodowi źródłowemu i większej interoperacyjności dzięki otwartym standardom i interfejsom.

Często mówi się również, że kod z otwartego źródła oferuje wysoki stopień bezpieczeństwa, ponieważ kod został zatwierdzony przez wielu użytkowników, a inteligencja roju społeczności open source umożliwia szybkie i skuteczne usuwanie błędów.

W praktyce to zaufanie musi być obecnie oceniane w sposób zróżnicowany i krytyczny. Najpoważniejszym przykładem jest luka bezpieczeństwa zero-day Log4Shell w szeroko stosowanej bibliotece logowania Log4J dla aplikacji Java, która została odkryta w listopadzie 2021 roku. Być może słyszeliście o czerwonym poziomie alertu wydanym przez niemiecki Federalny Urząd Bezpieczeństwa Informacji (BSI) dla Log4Shell. Biblioteka Log4J, dystrybuowana jako niezawodnie działający quasi-standard za pośrednictwem Apache Foundation, zadomowiła się w wielu systemach od 2013 roku - w tym w znanych usługach internetowych, takich jak Amazon AWS.

Złożoność tych dobrze rozwiniętych i również utrzymywanych bibliotek implicite zapewnia potężne funkcjonalności, z których importujący deweloper jest często nieświadomy w swoim własnym połączonym nowym rozwoju, ale które mogą być wykorzystane przez atakujących.

Innym czynnikiem braku bezpieczeństwa komponentów open source są tak zwane ataki łańcucha dostaw, czyli zamierzone wbudowane podatności przez złośliwe podmioty, które podają się za część społeczności open source i pomagają w rozwoju kodu. Taka podatność jest dla hakerów niezwykle skutecznym sposobem na zaatakowanie dużej liczby organizacji będących kolejnymi użytkownikami. Nic więc dziwnego, że ten wektor ataku gwałtownie rośnie: w badaniu Sonatype zdiagnozowano wzrost o 650% przy porównaniu lat 2020 i 2021.

neue-iso-iec-27001-2022-blog-dqs-projektmanager unterhalten sich bei benutzung eines tablets in einer zentrale
Loading...

Równie interesujące:

Nowa norma ISO/IEC 27001:2022 - kluczowe zmiany

Kontrola bezpieczeństwa informacji 8.28 bezpieczne kodowanie

W celu zabezpieczenia procesu tworzenia oprogramowania w odpowiednim czasie, Międzynarodowa Organizacja Normalizacyjna (ISO - komitet ISO/IEC JTC 1/SC 27) włączyła "Bezpieczne kodowanie" jako nową kontrolę 8.28 do nowych norm ISO/IEC 27002 i ISO/IEC 27001:2022, załącznik A. Celem środka technicznego dla bezpiecznego kodowania jest prewencyjna ochrona oprogramowania.

Minimalny poziom bezpieczeństwa jest tworzony już na etapie pisania na podstawie regulacji proceduralnych, dzięki czemu minimalizuje się liczbę potencjalnych luk bezpieczeństwa w oprogramowaniu. Regulacje prawne dotyczące tworzenia bezpiecznego kodu mają być stosowane holistycznie zarówno do własnego kodu programu, jak i do oprogramowania pochodzącego od osób trzecich i ze źródeł open source. Godnymi uwagi zasadami do wdrożenia są Security by Design oraz Least Privilege, które należy uwzględnić również w kodowaniu.

Zasady bezpiecznego kodowania

Działanie 8.28 kilkakrotnie odnosi się do tzw. zasad bezpiecznego kodowania. Wskazówki dotyczące tego, jakie mogą być, są dostarczane przez liczne organizacje i instytuty, które regularnie wydają przewodniki i najlepsze praktyki bezpiecznego kodowania. Należą do nich na przykład Secure Coding Practices Fundacji OWASP, Secure Coding Standards Zespołu Reagowania na Incydenty Komputerowe (CERT) Instytutu Inżynierii Oprogramowania (SEI) oraz katalog środków bezpieczeństwa aplikacji internetowych niemieckiego BSI. Pomimo różnych źródeł, opracowania wykazują wiele podobieństw, na przykład w odniesieniu do następujących punktów:

  • Walidacja wprowadzanych danych
  • Bezpieczne uwierzytelnianie i zarządzanie hasłami
  • Bezpieczna kontrola dostępu
  • Prosty, przejrzysty kod
  • Trwale przetestowane środki i komponenty kryptograficzne
  • Obsługa błędów i logowanie
  • Ochrona danych
  • Modelowanie zagrożeń

W normie ISO/ISO 27002:2022 zalecane działania dla kontroli 8.28 podzielone są na trzy sekcje "Planowanie i wstępne kodowanie", "Podczas kodowania" oraz "Weryfikacja i utrzymanie", których zasadnicza treść została przedstawiona poniżej.

Cyberattack - Bildschirm zeigt Zahlencodes mit Warnsignalen
Loading...

To może także być interesujące

Wykrywanie i zapobieganie w zarządzaniu bezpieczeństwem informacji

Planowanie i wstępne kodowanie

Zarówno tworzenie nowego kodu, jak i ponowne wykorzystanie kodu wymaga zastosowania zasad bezpiecznego kodowania - niezależnie od tego, czy kod jest pisany dla oprogramowania wewnętrznego, czy dla produktów i usług zewnętrznych. Wymaga to oceny oczekiwań specyficznych dla danej organizacji i zdefiniowania uznanych zasad z wyprzedzeniem. Ponadto, zalecane działania w zakresie planowania i prekodowania uwzględniają znane powszechne i historyczne praktyki kodowania oraz błędy, które mogą prowadzić do powstania podatności.

Konfiguracja narzędzi programistycznych, takich jak oparte na regułach zintegrowane środowiska programistyczne (IDE), powinna wymuszać tworzenie bezpiecznego kodu. Bardzo ważne są kwalifikacje programistów oraz ich znajomość bezpiecznych architektur i standardów programowania. Nie trzeba dodawać do zespołu programistów wiedzy z zakresu bezpieczeństwa informacji.

Podczas procesu kodowania

Podczas procesu kodowania główną rolę odgrywają praktyki kodowania i techniki programowania strukturalnego, uwzględniające konkretny przypadek użycia i jego potrzeby w zakresie bezpieczeństwa. Niebezpieczne techniki projektowania - na przykład twardo zakodowane hasła - powinny być konsekwentnie zabronione. Kod powinien być odpowiednio udokumentowany i przejrzany, aby jak najlepiej wyeliminować błędy związane z bezpieczeństwem. Przegląd kodu powinien odbywać się zarówno w trakcie, jak i po zakończeniu rozwoju, poprzez statyczne testy bezpieczeństwa aplikacji (SAST) lub podobne. Metody testowania statycznego wspierają podejście shift left ("testuj wcześnie i często"), przesuwając się w lewo w cyklu życia poprzez wczesne testowanie widocznego kodu pod kątem zgodności z regułami.

Pozwala to na wczesną identyfikację skażonego kodu, połączeń z plikami lub określonymi klasami obiektów, lub luk na poziomie aplikacji, które mogą być nadużywane do niezauważonej interakcji z programami stron trzecich jako podatności do wykorzystania. Przed uruchomieniem oprogramowania kontrola 8.28 wymaga oceny powierzchni ataku i wdrożenia zasady najmniejszych uprawnień. Ocenie powinna podlegać przeprowadzona analiza najczęściej występujących błędów programistycznych oraz dokumentacja ich poprawy.

Weryfikacja i utrzymanie

Nawet po uruchomieniu oprogramowania, temat bezpiecznego kodowania pozostaje aktualny. Dotyczy to zarówno bezpiecznych aktualizacji, jak i sprawdzania znanych podatności w swoim kodzie. Ponadto, błędy i podejrzane ataki muszą być udokumentowane, aby można było szybko wprowadzić niezbędne poprawki. W każdym przypadku, nieautoryzowany dostęp do kodu źródłowego musi być niezawodnie uniemożliwiony przez odpowiednie narzędzia.

Otwarty kod źródłowy

W obszarze weryfikacji i utrzymania, Działanie 8.28 wymienia dodatkowo wyraźne instrukcje dotyczące stosowania zewnętrznych narzędzi i bibliotek, takich jak oprogramowanie open source. Te składniki kodu powinny być zarządzane, aktualizowane i utrzymywane w spisach. Można to zrobić na przykład za pomocą listy materiałowej oprogramowania (SBOM). SBOM jest formalnym, ustrukturyzowanym zapisem pakietów i bibliotek oprogramowania oraz ich relacji między sobą i w ramach łańcucha dostaw, w szczególności w celu śledzenia ponownie wykorzystywanego kodu i składników open source. SBOM wspiera utrzymanie oprogramowania i ukierunkowane aktualizacje bezpieczeństwa.

fragen-antwort-dqs-fragezeichen auf wuerfeln aus holz auf tisch
Loading...

Certyfikacja zgodnie z ISO 27001

Z jakim wysiłkiem musisz się liczyć, aby Twój ISMS został certyfikowany zgodnie z ISO 27001? Uzyskaj informacje bezpłatnie i bez zobowiązań.

Czekamy na rozmowę z Państwem.

Wnioski

Bezpieczny kod to elementarna podstawa do powstrzymania potencjalnych ataków. Nowa Kontrola 8.28 bierze pod uwagę to długo cierpiące spostrzeżenie i podnosi kluczową rolę bezpiecznego kodowania w jego znaczeniu dla bezpieczeństwa informacji. Ponieważ jednak środek obejmuje dużą liczbę szczegółowych zaleceń dotyczących działań i jest technicznie wymagający, jego wdrożenie będzie wiązało się ze stosunkowo dużym wysiłkiem - należy to uwzględnić już na etapie planowania.

Dzięki profesjonalnemu spojrzeniu naszych doświadczonych audytorów, wspieramy Państwa w zgodnym z przepisami wdrożeniu działania. Dzięki naszemu ponad 35-letniemu doświadczeniu w zakresie audytów i certyfikacji jesteśmy Państwa idealnym partnerem do kontaktu i chętnie pomożemy Państwu w temacie bezpieczeństwa informacji i certyfikacji zgodnie z normami ISO/IEC 27001:2022.

Rewizja normy ISO 27001: Co aktualizacja oznacza dla Twojej certyfikacji?

Norma ISO/IEC 27001:2022 została opublikowana 25 października 2022 roku. Skutkuje to następującymi terminami i ramami czasowymi dla użytkowników:

Ostatnia data audytów początkowych/re-certyfikacyjnych zgodnie ze "starą" normą ISO 27001:2013

  • Po 30 kwietnia 2024 r. DQS będzie przeprowadzać audyty początkowe i recertyfikacyjne wyłącznie zgodnie z nową normą ISO/IEC 27001:2022.

Przejście wszystkich istniejących certyfikatów zgodnie ze "starą" normą ISO/IEC 27001:2013 na nową normę ISO/IEC 27001:2022

  • Od 31 października 2022 r. obowiązuje 3-letni okres przejściowy
  • Certyfikaty wydane zgodnie z ISO/IEC 27001:2013 lub DIN EN ISO/IEC 27001:2017 są ważne najpóźniej do 31 października 2025 r. lub muszą zostać wycofane w tym dniu.

DQS: Simply leveraging Security.

Ze względu na okresy przejściowe, firmy mają wystarczająco dużo czasu, aby dostosować swój ISMS zgodnie z nowymi wymaganiami i uzyskać jego certyfikat. Nie należy jednak lekceważyć czasu trwania i wysiłku związanego z całym procesem zmian - zwłaszcza jeśli nie dysponujesz wystarczającą ilością wyspecjalizowanego personelu. Jeśli chcesz być po bezpiecznej stronie, powinieneś zająć się tą kwestią raczej wcześniej niż później i w razie potrzeby skorzystać z pomocy doświadczonych specjalistów.

Jako eksperci od audytów i certyfikacji z ponad 35-letnim doświadczeniem, chętnie pomożemy Ci w ocenie Twojego aktualnego statusu, być może w ramach audytu delta. Dowiedz się od naszych licznych doświadczonych audytorów o najważniejszych zmianach i ich znaczeniu dla Twojej organizacji. Wspólnie omówimy możliwości poprawy i będziemy Cię wspierać aż do otrzymania nowego certyfikatu. Skorzystaj z naszych kompetencji w zakresie bezpieczeństwa informacji! Czekamy na kontakt z Państwem.

fragen-antwort-dqs-fragezeichen auf wuerfeln aus holz auf tisch
Loading...

Masz pytania?

Skontaktuj się z nami!

Bez zobowiązań i bezpłatnie.

Autor
Markus Jegelka

Ekspert DQS w zakresie systemów zarządzania bezpieczeństwem informacji (ISMS) i wieloletni audytor norm ISO 9001, ISO/IEC 27001 oraz katalogu bezpieczeństwa IT zgodnie z paragrafem 11.1a niemieckiej ustawy o przemyśle energetycznym (EnWG).

Loading...