Poprawki bezpieczeństwa w oprogramowaniu i regularne wydawanie aktualizacji mogą stanowić wyzwanie, ale są niezbędne do utrzymania cyberbezpieczeństwa w startupach. Poprawki bezpieczeństwa naprawiają błędy w kodzie, które mogą uczynić oprogramowanie podatnym na wykorzystanie przez złośliwych aktorów. Poprawianie luk w oprogramowaniu, systemach operacyjnych i systemach wbudowanych poprawia bezpieczeństwo startupu.

Czym jest poprawka bezpieczeństwa?

Wyobraź sobie oprogramowanie jako samochód, który wymaga konserwacji, aby działał poprawnie, poprawki bezpieczeństwa jako przegląd techniczny, a programistę jako mechanika. Kiedy twój samochód (oprogramowanie) działa już od jakiegoś czasu i potrzebuje wymiany oleju (aktualizacji), mechanik (programista) może wymienić olej w silniku na nowy. Podobnie, gdy mechanik postanawia sprawdzić wszystko w samochodzie, aby upewnić się, że nie ma ukrytych usterek, które muszą zostać naprawione, odkrywa problem z układem napędowym, który nie był zauważalny ani dla ciebie, ani dla nikogo, i naprawia go, zanim będzie za późno i samochód się zepsuje.

Dlaczego ważne jest, aby startupy stosowały poprawki bezpieczeństwa?

Startup powinien stosować najlepsze praktyki w zakresie poprawiania luk w oprogramowaniu i jak najszybciej wydawać aktualizacje dla swoich klientów, aby uniknąć bycia ofiarą ataków złośliwego kodu. Skanowanie podatności należy do tych najlepszych praktyk, które przypominają mechanika, który skanuje samochód za pomocą narzędzia diagnostycznego i sprawdza wszelkie problemy, które mogą być nieznane tobie lub innym. Naprawianie tych problemów i stosowanie automatycznych aktualizacji zaufanych sieci może zapobiec atakom złośliwego oprogramowania.

Podatności N-Dniowe

Podatności N-Dniowe (lub 1-dniowe) to rodzaj słabości w zabezpieczeniach, które są rozpoznawane przez programistów oprogramowania lub producentów sprzętu i zostają odkryte przez dostawcę lub cyberprzestępców. Podatności Zero-Day to przeciwieństwo podatności N-Dniowych, ponieważ są to słabości w zabezpieczeniach, które są nieznane dostawcom. W przypadku podatności N-Dniowych mogą już zostać wydane poprawki lub są w trakcie opracowywania i stosowania.

Największym wyzwaniem w stosowaniu poprawek dla podatności N-Dniowych jest zminimalizowanie luki czasowej pomiędzy wydaniem poprawek a czasem ich zastosowania. Złośliwi aktorzy i zaawansowane grupy APT (Advanced Persistent Threat) mogą wykorzystać niezaktualizowane podatności N-Dniowe.

Aby wyjaśnić, jak to działa, posłużmy się przykładem fikcyjnej firmy (Firma A), która korzysta z produktu firm trzecich (Produkt X).

Załóżmy, że na dzień 1 badacz bezpieczeństwa odkrył podatność N-Dniową w Produkcie X. Badacz bezpieczeństwa zgłasza zidentyfikowaną podatność do dostawcy Produktu X. Dostawca zaczyna natychmiast tworzyć poprawkę i wydaje ją dnia 4. Producent Produktu X powiadamia firmy korzystające z jego produktów o konieczności zaktualizowania Produktu X i zastosowania nowej poprawki. Część firm reaguje natychmiastowym wdrożeniem poprawki w swoich urządzeniach, inne potrzebują czasu, a część nigdy nie aktualizuje Produktu X.

Firma A, w szczególności, korzysta z Produktu X i opóźnia zastosowanie poprawki o 60 dni po powiadomieniu jej przez dostawcę o jej wydaniu. Oznacza to, że cyberprzestępcy mieli 60 dni na wykorzystanie tej podatności w Firmie A i wyrządzenie jej szkody.

EternalBlue 

EternalBlue to narzędzie hakerskie stworzone przez amerykańską Agencję Bezpieczeństwa Narodowego (NSA), które zostało skradzione przez grupę cyberprzestępczą Shadow Brokers. EternalBlue celowało w lukę 0-day w protokole udostępniania plików Server Message Block (SMB) w wersji 1, czyli SMBv1. Grupa Shadow Brokers udostępniła EternalBlue publicznie, po czym Microsoft wydał łatkę rozwiązującą tę podatność. Od tego momentu luka została sklasyfikowana jako podatność 1-day (lub n-day). Niemniej jednak, nie powstrzymało to cyberprzestępców przed wykorzystywaniem tej podatności i używaniem EternalBlue do przeprowadzania kampanii ransomware. Różne grupy cyberprzestępcze wykorzystywały EternalBlue przez trzy miesiące po wydaniu łatki do ataku ransomware WannaCry w 2017 roku.

Serwery Windows, które nie zostały załatane i były połączone z Internetem, wciąż były zagrożone przez exploit EternalBlue, a ponad 100 różnych źródeł wykorzystywało go do codziennych ataków na systemy. W maju 2017 roku setki tysięcy systemów komputerowych nadal były zarażane, co prowadziło do utraty danych i zakłóceń w ich działaniu. Dodatkowo, ponad 600 000 serwerów nadal umożliwiało połączenia SMB przez publiczny Internet. Część z tego wynikała z faktu, że niektóre firmy musiały utrzymywać otwarty port SMB, aby wspierać krytyczne aplikacje legacy.

Luki N-day stają się łatwe do wykorzystania, gdy firmy ich nie załatują, co daje więcej czasu aktorom złośliwym na ich wykorzystanie. Ponadto, rzeczywistość jest taka, że złośliwi aktorzy na dark webie mogą sprzedawać i pobierać exploity dla luk N-day jako część swojego modelu subskrypcyjnego Ransomware-as-a-Service (RaaS), dlatego tak ważne jest jak najszybsze załatanie podatności.

Narzędzia do skanowania podatności

Używanie skanera podatności to prosty i kluczowy sposób na sprawdzenie luk w zabezpieczeniach, który dostarcza również informacji o potencjalnych słabościach w zabezpieczeniach startupu lub organizacji. Są one głównie wykorzystywane do skanowania sieci i aplikacji webowych pod kątem podatności.

Poniżej znajduje się lista skanerów podatności, które startup może wykorzystać:

• Nmap
• BurpSuite
• Tenable Nessus
• Acutenix
• beSECURE
• GFI Languard
• Frontline
• Tripwire IP360
• OpenVAS
• Qualys Guard 
• Qualys Web Application Scanner
• SAINT
• Nexpose

Zarządzanie poprawkami

Proces zarządzania poprawkami w startupach może wymagać znacznego wysiłku, ale w niektórych przypadkach może nie być koniecznością dla utrzymania dobrej postawy bezpieczeństwa. W innych startupach warto wdrożyć uproszczony proces zarządzania poprawkami. Procedury i wdrożenie procesu zarządzania poprawkami zależą od decyzji startupu. Z tego powodu przedstawiam ogólny opis procesu zarządzania poprawkami w dojrzałych organizacjach. W zakresie cyberbezpieczeństwa startupów zaleca się zidentyfikowanie kluczowych elementów procesu zarządzania poprawkami i ich wdrożenie.

Zarządzanie poprawkami realizowane w dojrzałych organizacjach usuwa wykryte luki bezpieczeństwa. Zarządzanie poprawkami jest cenne dla poprawy bezpieczeństwa, wydajności, takiej jak dostępność systemu, przestrzegania standardów zgodności i daje możliwość wprowadzania aktualizacji funkcji/nowych funkcjonalności po usunięciu błędów oprogramowania. Oprócz zwiększenia bezpieczeństwa organizacji, satysfakcja klientów może wzrosnąć, gdy będą zadowoleni z wyników aktualizacji oprogramowania. Innymi słowy, proces zarządzania poprawkami to procedura typu win-win.

Poniżej opisano kroki procesu zarządzania poprawkami:

1. Opracuj aktualny inwentarz wszystkich systemów produkcyjnych: Możesz monitorować, jakie zasoby znajdują się w Twoim ekosystemie, utrzymując aktualny inwentarz wszystkich systemów produkcyjnych. Dbanie o bieżące aktualizowanie inwentarza zasobów pozwala na uzyskanie świadomego obrazu posiadanych zasobów.
2. Opracuj plan standaryzacji systemów i systemów operacyjnych na ten sam typ wersji: Ujednolicenie inwentarza zasobów do zarządzalnej liczby pozwala na szybsze i bardziej efektywne stosowanie poprawek, mimo że może to być wyzwaniem. Standaryzowanie systemów oszczędza czas w procesie naprawy i przyspiesza go, gdy nowe poprawki są udostępniane.
3. Sporządź listę wszystkich kontrolerów bezpieczeństwa, które są wdrożone w organizacji: Śledź swoje zapory sieciowe, oprogramowanie antywirusowe i narzędzia do zarządzania podatnościami. Wiedz, gdzie się znajdują, co chronią i jakie zasoby są z nimi powiązane.
4. Porównaj zgłoszone podatności z inwentarzem: Skorzystaj z narzędzia do zarządzania podatnościami, aby ocenić, które podatności występują w jakich zasobach Twojego ekosystemu, co pomoże Ci zrozumieć ryzyko w postawie bezpieczeństwa organizacji.
5. Klasyfikuj ryzyko: Priorytetyzuj, które podatności należy usunąć jako pierwsze na podstawie ich powagi. Dzięki narzędziom do zarządzania podatnościami łatwo zarządzasz zasobami, które są krytyczne dla Twojej organizacji. Dla startupu istotne jest, aby wiedzieć, które poprawki są najważniejsze. Przydatnym narzędziem jest System Oceny Wrażliwości Podatności (CVSS), który ocenia powagę podatności bezpieczeństwa w szerokim zakresie produktów oprogramowania. Więcej na temat CVSS można przeczytać w jednym z naszych poprzednich artykułów.
6. TESTUJ! Zastosuj poprawki na reprezentatywnej próbce zasobów w środowisku laboratoryjnym. Przetestuj obciążeniowo maszyny, aby upewnić się, że poprawki nie spowodują problemów w środowisku produkcyjnym.
7. Zastosuj poprawki: Zastosuj poprawki, aby zredukować ryzyko bezpieczeństwa w swoim środowisku, po priorytetyzacji tego, co powinno zostać naprawione jako pierwsze, na podstawie poziomu krytyczności. Bardziej zaawansowane narzędzia do zarządzania podatnościami oferują także możliwość automatyzacji czasochłonnych części procesu stosowania poprawek.
8. Śledź postępy: Ponownie oceń zasoby, aby upewnić się, że poprawki zostały pomyślnie zastosowane.

Najlepsze praktyki procesu zarządzania łatkami

Podczas wdrażania zarządzania łatkami, równie ważne jest przestrzeganie tych najlepszych praktyk przez zespół organizacji:

• Ustalanie jasnych oczekiwań i pociąganie zespołów do odpowiedzialności: Wykorzystanie umów organizacyjnych, takich jak umowa o poziomie usług (SLA), daje zespołom technicznym coś do przestrzegania, co pozwala im wdrożyć działania, które zmniejszają ryzyko związane z bezpieczeństwem.
• Współpraca z zespołami technicznymi w celu zapewnienia wspólnego języka: Zespoły bezpieczeństwa często odnoszą się do błędów oprogramowania jako „ryzyka”, podczas gdy zespoły IT/DevOps mogą używać innych terminów, takich jak „łatka”. Różnice w używanym języku mogą prowadzić do problemów komunikacyjnych. Proces zarządzania łatkami jest skuteczny, gdy wszyscy członkowie zespołu organizacji rozumieją się nawzajem i wszyscy dostrzegają znaczenie łatania.
• Ustalenie procesu odzyskiwania po awarii: W przypadku, gdy proces zarządzania łatkami zawiedzie i spowoduje problemy, zawsze należy mieć plan awaryjny.

Spełnianie wymagań zgodności z zarządzaniem łatkami

Zarządzanie łatkami musi być zgodne z normami, takimi jak wymagania PCI DSS, w tym wymagania 6.1-6.7.

Poniżej przedstawiono wymagania zgodności PCI DSS:

• Wymaganie PCI DSS 6.1: Ustanowienie procesu identyfikacji podatności przy użyciu wiarygodnych źródeł zewnętrznych oraz przypisanie rankingu ryzyka nowo odkrytym podatnościom.
• Wymaganie PCI DSS 6.2: Zapewnienie ochrony wszystkich składników systemu i oprogramowania przed znanymi podatnościami poprzez instalację odpowiednich łat zabezpieczających dostarczonych przez producenta. Instalacja krytycznych łat zabezpieczających w ciągu miesiąca.
• Wymaganie PCI DSS 6.3: Bezpieczne opracowywanie aplikacji wewnętrznych i zewnętrznych.
• Wymaganie PCI DSS 6.3.1: Usunięcie kont użytkowników, identyfikatorów użytkowników i haseł z aplikacji deweloperskich, testowych lub niestandardowych przed udostępnieniem aplikacji użytkownikom.
• Wymaganie PCI DSS 6.3.2: Przeprowadzanie przeglądów kodu przed aktywowaniem aplikacji lub jej udostępnieniem użytkownikom w celu wykrycia możliwych podatności w kodzie.
• Wymaganie PCI DSS 6.4: Przestrzeganie procesów i procedur kontroli zmian dla wszystkich zmian składników systemu.
• Wymaganie PCI DSS 6.4.1: Oddzielenie środowisk deweloperskich i testowych od środowisk produkcyjnych i wdrożenie oddzielenia z kontrolą dostępu.
• Wymaganie PCI DSS 6.4.2: Wymagane jest oddzielenie obowiązków między środowiskiem deweloperskim, testowym i produkcyjnym.
• Wymaganie PCI DSS 6.4.3: Dane produkcyjne (żywe numery PAN) nie mogą być wykorzystywane do testów lub rozwoju.
• Wymaganie PCI DSS 6.4.4: Dane testowe i konta muszą zostać usunięte z komponentów systemu przed uruchomieniem systemu.
• Wymaganie PCI DSS 6.5: Rozwiązywanie typowych podatności w procesach rozwoju oprogramowania.
• Wymaganie PCI DSS 6.5.1: Rozważanie wad związanych z wstrzyknięciami, w tym SQL injection, OS Command Injection, LDAP i XPath injection, jak również innych wad wstrzyknięć.
• Wymaganie PCI DSS 6.5.2: Przepełnienia bufora.
• Wymaganie PCI DSS 6.5.3: Niebezpieczne przechowywanie kryptograficzne.
• Wymaganie PCI DSS 6.5.4: Niezabezpieczona komunikacja.
• Wymaganie PCI DSS 6.5.5: Niewłaściwe zarządzanie błędami.
• Wymaganie PCI DSS 6.5.6: Wszystkie „wysokiego ryzyka” podatności zidentyfikowane w procesie identyfikacji podatności muszą zostać rozwiązane.
• Wymaganie PCI DSS 6.5.7: Cross-Site Scripting (XSS).
• Wymaganie PCI DSS 6.5.8: Niewłaściwa kontrola dostępu.
• Wymaganie PCI DSS 6.5.9: Cross-Site Request Forgery (CSRF).
• Wymaganie PCI DSS 6.5.10: Złamana autentykacja i zarządzanie sesjami.
• Wymaganie PCI DSS 6.6: Ciągłe rozwiązywanie nowych zagrożeń i podatności dotyczących aplikacji internetowych i zapewnienie, że te aplikacje są chronione przed znanymi atakami.
• Wymaganie PCI DSS 6.7: Zapewnienie, że polityki bezpieczeństwa i procedury operacyjne dotyczące tworzenia i utrzymywania bezpiecznych systemów i aplikacji są udokumentowane, stosowane i znane wszystkim zainteresowanym stronom.

Zarządzanie ryzykiem w cyberbezpieczeństwie

Zarządzanie ryzykiem w cyberbezpieczeństwie to ciągły proces identyfikowania, analizowania, oceny i rozwiązywania zagrożeń związanych z cyberbezpieczeństwem, z którymi może spotkać się startup. Rola zespołów w zarządzaniu ryzykiem cyberbezpieczeństwa zależy od organizacji. W niektórych organizacjach zarządzanie ryzykiem to wyłącznie zadanie zespołu ds. bezpieczeństwa, w innych może być podzielone pomiędzy zespoły DevSecOps i DevOps. Często współpraca między zespołami odgrywa istotną rolę w zarządzaniu ryzykiem. Ponadto zapewnienie pracownikom wszystkich działów szkoleń z zakresu świadomości cyberbezpieczeństwa może pomóc zmniejszyć ryzyko zagrożeń związanych z cyberbezpieczeństwem, zwłaszcza ataków phishingowych.

Oto kluczowe elementy działań zarządzania ryzykiem, które startupy i organizacje powinny mieć na uwadze:

• Opracowanie solidnych polityk i narzędzi do oceny ryzyka dostawców
• Identyfikacja nowych ryzyk, takich jak nowe regulacje mające wpływ na działalność
• Identyfikacja wewnętrznych słabości, takich jak brak uwierzytelniania dwuetapowego
• Ograniczanie ryzyka IT, np. poprzez programy szkoleniowe lub nowe polityki i kontrolę wewnętrzną
• Testowanie ogólnego stanu bezpieczeństwa
• Dokumentacja zarządzania ryzykiem dostawców i bezpieczeństwa w celu przeprowadzenia kontroli regulacyjnych lub w celu zaspokojenia oczekiwań potencjalnych klientów

Oprogramowanie po zakończeniu cyklu życia

End-of-life (EOL), when referring to a piece of software or product, is referring to the end of its lifecycle. A software vendor may end or limit its support on software or products and/or its versions to focus on new innovations. This can create issues for customers who continue to use outdated and obsolete software because they become vulnerable to malicious attacks when vulnerabilities are no longer patched. As malicious actors become more creative and advanced over time with the advancement of tools and access to more resources, it creates more opportunities for them to exploit outdated software. It is strongly recommended to keep up to date with the latest version of software and when software has reached end-of-life, finding an up-to-date alternative is pragmatic.

Five end-of-life software dangers also include:

1. Incompatible software — New releases of software have been optimized for the most recent operating systems. With an EOL OS that you cannot upgrade, you may be forced to continue running older applications. These apps themselves are probably facing their own EOLs, too.
2. New vulnerabilities — When a vendor stops issuing security patches, your system becomes a sitting duck for cybercriminals—who will quickly start searching the globe for people who continue to operate in this defenseless mode. Using firewalls and anti-malware countermeasures are not enough to protect your servers from attacks that exploit unpatchable vulnerabilities.
3. Added expense — The operating costs required to maintain and fix bugs on an OS that’s post-EOL can be quite high. In addition, you should estimate the business impact, in dollars, of an outage caused by the EOL OS.
4. Compliance challenges — Regulatory compliance frameworks usually mandate regular patching.  The audit and certification process for systems in regulated industries like healthcare and finance may prohibit the use of EOL systems.
5. Poor performance and reduced reliability — Running legacy apps on EOL OS’s leads to performance and reliability issues. Aging systems tend to break down more often than their more up-to-date and patched counterparts. It’s wise to think through the effects of the inevitable downtime that will come with an EOL OS.

Termin „koniec cyklu życia” (EOL – End-of-Life), odnoszący się do oprogramowania lub produktu, oznacza koniec jego cyklu życia. Dostawca oprogramowania może zakończyć lub ograniczyć wsparcie dla oprogramowania lub produktów i/lub ich wersji, aby skupić się na nowych innowacjach. Może to stworzyć problemy dla klientów, którzy nadal korzystają z przestarzałego oprogramowania, ponieważ staje się ono podatne na ataki, gdy luki bezpieczeństwa nie są już łatanie. W miarę jak atakujący stają się coraz bardziej kreatywni i zaawansowani, korzystając z narzędzi i dostępu do zasobów, rośnie liczba możliwości wykorzystania przestarzałego oprogramowania. Zdecydowanie zaleca się utrzymywanie oprogramowania w najnowszej wersji, a gdy oprogramowanie osiągnie koniec cyklu życia, znalezienie aktualnej alternatywy jest pragmatycznym rozwiązaniem.

Pięć zagrożeń związanych z oprogramowaniem po zakończeniu cyklu życia obejmuje:

1. Niezgodne oprogramowanie — Nowe wersje oprogramowania są zoptymalizowane pod kątem najnowszych systemów operacyjnych. W przypadku systemu operacyjnego po zakończeniu cyklu życia, którego nie można zaktualizować, użytkownik może być zmuszony do korzystania ze starszych aplikacji. Te aplikacje również prawdopodobnie będą miały swoje własne końce cyklu życia.
2. Nowe luki bezpieczeństwa — Gdy dostawca przestaje wydawać poprawki zabezpieczeń, system staje się łatwym celem dla cyberprzestępców, którzy szybko zaczynają szukać osób, które wciąż działają w trybie bez obrony. Korzystanie z zapór ogniowych i środków przeciwdziałania złośliwemu oprogramowaniu nie wystarcza do ochrony serwerów przed atakami wykorzystującymi nieusuwalne luki.
3. Wyższe koszty — Koszty operacyjne związane z utrzymaniem i naprawą błędów w systemie operacyjnym po zakończeniu cyklu życia mogą być wysokie. Ponadto należy oszacować wpływ na działalność, w dolarach, przerwy spowodowane przez system operacyjny po zakończeniu cyklu życia.
4. Wyzwania związane z zgodnością — Ramy zgodności regulacyjnej zazwyczaj nakładają obowiązek regularnego łatania. Proces audytu i certyfikacji systemów w regulowanych branżach, takich jak opieka zdrowotna i finanse, może zakazywać korzystania z systemów po zakończeniu cyklu życia.
5. Słabsza wydajność i niezawodność — Uruchamianie aplikacji legacy na systemach operacyjnych po zakończeniu cyklu życia prowadzi do problemów z wydajnością i niezawodnością. Starsze systemy psują się częściej niż te bardziej aktualne i załatane. Warto zastanowić się nad konsekwencjami nieuniknionych przestojów związanych z systemem operacyjnym po zakończeniu cyklu życia.

Podsumowanie

Luki bezpieczeństwa w oprogramowaniu należy usunąć jak najszybciej, ponieważ czas działa na korzyść atakujących, którzy mogą je wykorzystać do przeprowadzenia ataku złośliwego oprogramowania. Wdrażając zarządzanie łatkami i zarządzanie ryzykiem, stosując najlepsze praktyki bezpieczeństwa, przestrzegając standardów zgodności, w tym utrzymując aktualność oprogramowania z zaufanych sieci, oraz na bieżąco monitorując inwentaryzację zasobów, stan bezpieczeństwa organizacji lub startupu poprawi się w przyspieszonym tempie. Wszystko to może wymagać znacznych zasobów, jednak wiedza na temat tych aspektów i wybranie najważniejszych z nich zwiększy cyberbezpieczeństwo startupów.

Źródła:

• https://zigrin.com/vulnerability-severity-in-web-application-penetration-testing-cvss
• https://www.cisa.gov/uscert/ncas/tips/ST04-006
• https://www.rapid7.com/fundamentals/patch-management
• https://www.coresecurity.com/blog/top-14-vulnerability-scanners-cybersecurity-professionals
• https://www.techtarget.com/searchsecurity/answer/Testing-a-security-patch
• https://retaintechnologies.com/en/how-to-easily-update-and-maintain-asset-inventory
• https://hyperproof.io/resource/cybersecurity-risk-management-process
• https://endoflife.software/what-is-eolhttps://blog.cloudlinux.com/5-risks-of-using-end-of-life-operating-system
• https://www.darkreading.com/vulnerabilities-threats/eternalblue-longevity-underscores-patching-problem
• https://usa.kaspersky.com/resource-center/threats/ransomware-wannacry
• https://www.crowdstrike.com/cybersecurity-101/ransomware/ransomware-as-a-service-raas