Efektywne zarządzanie podatnościami na zagrożenia. Jak minimalizować ryzyko w cyfrowym ekosystemie - ebook
Efektywne zarządzanie podatnościami na zagrożenia. Jak minimalizować ryzyko w cyfrowym ekosystemie - ebook
Musisz sobie uświadomić, że korzystanie z systemów opartych na chmurze wiąże się z cyberzagrożeniami - podobnie jak w przypadku tradycyjnej infrastruktury. Musisz się dobrze orientować w złożoności swojego systemu i w powiązaniach poszczególnych elementów. Dopiero na tej podstawie możesz planować i ustalać priorytety we własnym programie zarządzania ryzykiem, uwzględniając przy tym wiele innych zagadnień.
W tej praktycznej książce znajdziesz opis kompleksowych praktyk, dzięki którym współczesne organizacje utrzymujące złożone ekosystemy oprogramowania mogą skutecznie identyfikować podatności, zarządzać nimi i ograniczać ryzyko wystąpienia poważnych naruszeń bezpieczeństwa. Dowiesz się, dlaczego nie wystarczy po prostu "użyć łatki", aby naprawić znane luki w oprogramowaniu. Poznasz zasady profesjonalnego zarządzania podatnościami uwzględniające monitorowanie systemów i baz danych podatności. Przekonasz się, jak ważne są czynnik ludzki i identyfikacja czynników psychologicznych, które podczas interakcji użytkownika z oprogramowaniem przyczyniają się do powstawania podatności. W miarę lektury książki przyswoisz wydajne i skuteczne strategie, dzięki którym zapewnisz swojej organizacji wysoki poziom cyberbezpieczeństwa.
Najciekawsze zagadnienia:
- zarządzanie złożonymi środowiskami
- poprawki do oprogramowania i bezpieczna konfiguracja
- ocena podatności i łączenie ich w łańcuch
- czynnik ludzki w zarządzaniu podatnościami
- oprogramowanie bezpieczne już na etapie projektu
- budowa dojrzałego modelu zarządzania podatnościami
Sprawdź, jak w erze chmury zarządzać ryzykiem informatycznym!
Spis treści
Przedmowa
Wprowadzenie
1. Zarządzanie aktywami
- Fizyczne i mobilne zarządzanie aktywami
- Aktywa IoT konsumenta
- Aktywa programistyczne
- Zarządzanie aktywami w chmurze
- Środowiska wielochmurowe
- Hybrydowe środowiska chmury
- Oprogramowanie innych firm oraz oprogramowanie open source (OSS)
- Oprogramowanie innych firm (i związane z nim ryzyko)
- Uwzględnianie oprogramowania open source
- Inwentaryzacja aktywów lokalnych i w chmurze
- Lokalne centra danych
- Oprzyrządowanie
- Narzędzia do zarządzania aktywami
- Narzędzia do sprawdzania podatności
- Narzędzia do zarządzania inwentarzem w chmurze
- Aktywa efemeryczne
- Źródła prawdy
- Ryzyko zarządzania aktywami
- Log4j
- Brakujące i nieuwzględnione aktywa
- Nieznane niewiadome
- Zarządzanie łataniem
- Zalecenia dotyczące zarządzania aktywami
- Odpowiedzialność przy zarządzaniu aktywami
- Wykrywanie aktywów
- Uzyskanie odpowiedniego oprzyrządowania
- Transformacja cyfrowa
- Standardowe procedury działania przy wprowadzaniu i wycofywaniu
- Podsumowanie
2. Zarządzanie łataniem
- Podstawy zarządzania łataniem
- Ręczne zarządzanie łataniem
- Ryzyko ręcznego łatania
- Oprzyrządowanie do ręcznego łatania
- Zarządzanie automatycznym łataniem
- Zalety łatania automatycznego w porównaniu z ręcznym
- Kombinacja łatania automatycznego i ręcznego
- Ryzyko przy automatycznym łataniu
- Zarządzanie łataniem w środowiskach deweloperskich
- Łatanie oprogramowania open source
- Niecałe oprogramowanie jest sobie równe
- Wewnętrzne zarządzanie łataniem
- Odpowiedzialność zespołów ds. infrastruktury i zespołów operacyjnych
- Kto jest właścicielem zarządzania łataniem?
- Podział obowiązków
- Narzędzia i raportowanie
- Łatanie przestarzałych systemów
- Przestarzałe oprogramowanie
- Niezałatane oprogramowanie open source
- Ryzyko szczątkowe
- Powszechne ataki na niezałatane systemy
- Ustalanie priorytetów działań związanych z łataniem
- Zarządzanie ryzykiem i łatanie
- Tworzenie programu zarządzania łataniem
- Ludzie
- Proces
- Technologia
- Podsumowanie
3. Bezpieczna konfiguracja
- Regulacje, ramy i prawa
- Pierwsza dziesiątka wadliwych konfiguracji według NSA i CISA
- Domyślna konfiguracja oprogramowania i aplikacji
- Niewłaściwa separacja uprawnień użytkownika i administratora
- Niedostateczny monitoring sieci wewnętrznej
- Brak segmentacji sieci
- Słabe zarządzanie łataniem
- Omijanie systemu kontroli dostępu
- Słabe lub źle skonfigurowane wieloskładnikowe metody uwierzytelniania
- Brak MFA odpornych na phishing
- Niewystarczające listy kontrolne do udziałów i usług sieciowych
- Słaba higiena poświadczeń
- Nieograniczone wykonywanie kodu
- Ograniczanie zagrożeń
- Wzorce CIS (CIS Benchmark)
- Techniczne wytyczne implementacji zabezpieczeń DISA
- Podsumowanie
4. Ciągłe zarządzanie podatnościami
- Kontrola CIS 7 - ciągłe zarządzanie podatnościami
- Ustanowienie i utrzymanie procesu zarządzania podatnościami
- Ustanowienie i obsługa procesu naprawczego
- Zautomatyzowane zarządzanie poprawkami systemu operacyjnego
- Zautomatyzowane zarządzanie łataniem aplikacji
- Zautomatyzowane skanowanie wewnętrznych aktywów przedsiębiorstwa pod kątem podatności na zagrożenia
- Zautomatyzowane skanowanie podatności na zagrożenia zewnętrznych aktywów przedsiębiorstwa
- Eliminowanie wykrytych podatności
- Praktyki ciągłego monitorowania
- Podsumowanie
5. Ocena podatności i identyfikacja oprogramowania
- Powszechny system oceny podatności
- CVSS 4.0 w skrócie
- Miary bazowe
- Miary możliwości wykorzystania
- Miary zagrożenia
- Miary środowiskowe
- Miary dodatkowe
- Jakościowa skala oceny wagi
- Łańcuch wektorowy
- System oceny przewidywania exploitów
- EPSS 3.0 - ustalanie priorytetów poprzez przewidywanie
- EPSS 3.0
- Posuwamy się do przodu
- Kategoryzacja podatności na zagrożenia według interesariuszy
- Przewodnik CISA po SSVC
- Przykład drzewa decyzyjnego
- Formaty identyfikacji oprogramowania
- Schemat nazewnictwa (CPE)
- Package URL
- Znaczniki identyfikacyjne oprogramowania
- Lista podatności (CWE)
- Podsumowanie
6. Zarządzanie bazą danych podatności i exploitów
- Baza danych podatności NVD
- Indeks Sonatype oprogramowania open source
- Podatności oprogramowania open source
- Baza danych zaleceń GitHub
- Bazy danych exploitów
- Exploit-DB
- Metasploit
- GitHub
- Podsumowanie
7. Łączenie podatności w łańcuch
- Ataki z użyciem łańcucha podatności
- Łańcuchy exploitów
- Łańcuchy podatności
- Łańcuchy podatności publikowane przez sprzedawców
- Łączenie i ocena podatności
- CVSS
- EPSS
- Luki w branży
- Niedostrzeganie łączenia podatności
- Terminologia
- Wykorzystanie w programach zarządzania podatnościami
- Ludzki aspekt łączenia podatności na zagrożenia
- Phishing
- Naruszenie biznesowej poczty e-mail
- Inżynieria społeczna
- Integracja z VMP
- Zasady przywództwa
- Integracja z praktykiem ds. bezpieczeństwa
- Wykorzystanie IT i rozwoju
- Podsumowanie
8. Analiza zagrożeń związanych z podatnościami
- Dlaczego analiza zagrożeń jest ważna dla programu zarządzania podatnościami (VMP)?
- Od czego zacząć?
- Techniczne informacje o zagrożeniach
- Taktyczna analiza zagrożeń
- Strategiczna analiza zagrożeń
- Operacyjna analiza zagrożeń
- Polowanie na zagrożenia
- Integracja analizy zagrożeń z systemami VMP
- Ludzie
- Proces
- Technologia
- Podsumowanie
9. Chmura, DevSecOps i bezpieczeństwo łańcucha dostaw
- Modele usług chmurowych i współdzielona odpowiedzialność
- Środowiska hybrydowe i wielochmurowe
- Kontenery
- Kubernetes
- Przetwarzanie bezserwerowe
- DevSecOps
- Oprogramowanie open source
- Oprogramowanie jako usługa
- Ryzyko systemowe
- Podsumowanie
10. Czynnik ludzki w zarządzaniu podatnościami
- Inżynieria czynników ludzkich
- Inżynieria bezpieczeństwa czynników ludzkich
- Przełączanie kontekstu
- Pulpity podatności
- Raporty o podatności
- Poznanie i metapoznanie
- Poznawanie podatności
- Sztuka podejmowania decyzji
- Zmęczenie decyzyjne
- Zmęczenie alertami
- Liczba ujawnionych podatności
- Wymagane poprawki i konfiguracje
- Zmęczenie zarządzaniem podatnościami
- Psychiczne obciążenie pracą
- Integracja czynnika ludzkiego z VMP
- Zacznij od małych kroków
- Rozważenie skorzystania z pomocy konsultanta
- Podsumowanie
11. Secure-by-design, czyli oprogramowanie bezpieczne już na etapie projektu
- Bezpieczne już na etapie projektu/domyślnie
- Bezpieczne już na etapie projektu
- Domyślnie bezpieczne
- Zasady bezpieczeństwa oprogramowania
- Zasada 1. Przejęcie odpowiedzialności za wyniki w zakresie bezpieczeństwa klientów
- Zasada 2. Przyjęcie radykalnej przejrzystości i odpowiedzialności
- Zasada 3. Kierowanie od góry
- Taktyka bezpieczeństwa już na etapie od projektu
- Taktyka domyślnego bezpieczeństwa
- Przewodniki utwardzania kontra luzowania
- Zalecenia dla klientów
- Modelowanie zagrożeń
- Tworzenie bezpiecznego oprogramowania
- Szczegóły SSDF
- Bezpieczeństwo, inżynieria chaosu i odporność
- Podsumowanie
12. Model dojrzałości zarządzania podatnościami
- Krok 1. Zarządzanie aktywami
- Krok 2. Bezpieczna konfiguracja
- Krok 3. Ciągłe monitorowanie
- Krok 4. Zautomatyzowane zarządzanie podatnościami
- Krok 5. Integracja czynników ludzkich
- Krok 6. Analiza podatności na zagrożenia
- Podsumowanie
Podziękowania
O autorach
O korektorze merytorycznym
| Kategoria: | Hacking |
| Zabezpieczenie: |
Watermark
|
| ISBN: | 978-83-289-2161-0 |
| Rozmiar pliku: | 9,3 MB |
FRAGMENT KSIĄŻKI
_— CHRIS HUGHES_
_Dedykuję tę książkę mojemu mężowi, Brianowi, oraz moim córkom, Keirze i Teagan. Bez waszego nieustannego wsparcia i zachęty nigdy nie byłabym w stanie robić tego, co kocham. Jesteście moim światem._
_Tę książkę dedykuję również mojej babci Osbourn — jednej z najsilniejszych kobiet, jakie znam. Jestem szczęściarą, że mam tak niezależną i nieustraszoną babcię, na której mogę się wzorować._
_— DR NIKKI ROBINSON_PRZEDMOWA
Gdy pomagałem założyć Tenable Network Security, starałem się uprzedzić wszystkie sposoby, w jakie źli aktorzy włamywali się do sieci, za pomocą naszego systemu wykrywania włamań do sieci Dragon. Dzięki Dragonowi widzieliśmy wszelkiego rodzaju wrogie, najnowocześniejsze ataki państw i wykorzystywanie niezałatanych systemów, a także zuchwałych hakerów. Zakładając Tenable, współzałożyciele i ja chcieliśmy uczynić cyberbezpieczeństwo osiągalnym i możliwym do obrony celem. Ciągłe monitorowanie nie istniało jako pojęcie na początku XXI wieku. Normą były coroczne testy penetracyjne, a nawet kwartalne skanowanie podatności. Chcieliśmy, aby zagrożenia związane z cyberbezpieczeństwem stały się zrozumiałe dla osób i organizacji.
Wraz ze wzrostem wykorzystania Internetu i zależności od niego wzrosła liczba podmiotów stanowiących zagrożenie dla państw. Nasza branża zareagowała regulacjami i ramami IT. Do 2020 roku mieliśmy wymagania Payment Card Industry — szeroką gamę standardów rządowych, których kulminacją były ramy cyberbezpieczeństwa Narodowego Instytutu Standardów i Technologii (NIST), a także ramy MITRE ATT&CK. W tym samym czasie organizacja SANS opublikowała listę 20 największych podatności. Szybko stało się to trudne do zarządzania i zostało zastąpione przez SANS Top 20 Controls, które zostało przejęte przez Center for Internet Security (CIS). Widzieliśmy również, jak hakerzy przeszli od ataków typu odmowa usługi na strony internetowe na początku XXI wieku do paraliżujących ataków na państwa, które zamykały szpitale, stocznie i sklepy spożywcze.
Wraz ze wzrostem świadomości zagrożeń związanych z IT nowe rodzaje technologii zdawały się rozwijać szybciej. W latach 2000 – 2020 byliśmy świadkami wprowadzenia sieci Wi-Fi, urządzeń mobilnych, wirtualizacji, kontenerów, usług typu oprogramowanie jako usługa (SaaS), elastycznej infrastruktury chmurowej i urządzeń wbudowanych, a teraz zmagamy się z wdrażaniem sztucznej inteligencji (AI).
W ostatniej dekadzie byliśmy świadkami zwiększonej roli rządu USA w IT. Administracja Trumpa zakazała technologii sieciowych, takich jak drony, kamery bezpieczeństwa i urządzenia sieciowe z Chin, a także wprowadziła koncepcję _defend forward_, która jest nadal stosowana przez Agencję Bezpieczeństwa Narodowego (NSA). Administracja Bidena niedawno stworzyła Biuro Krajowego Dyrektora ds. Cyberbezpieczeństwa, które kieruje znaczną częścią strategii cybernetycznej rządu USA. Jest bardzo prawdopodobne, że pojawi się więcej regulacji, które wpłyną na sposób, w jaki zabezpieczamy Internet i z niego korzystamy.
Jednak od końca 2023 roku nie mamy spójnych przepisów ani zestawu zasad dotyczących zabezpieczania danych. Jeśli jesteś nowy w dziedzinie zarządzania podatnościami, może Ci się to wydawać zaskakujące. Sposób zarządzania podatnościami jest niezwykle subiektywny i opiera się na technologii, wrażliwości przechowywanych w niej danych, wyrafinowaniu aktorów zagrożeń, przed którymi się chronisz, dostępnym budżecie, pracownikach oraz szerokiej gamie wymogów politycznych, regulacyjnych i prawnych. To, co sprawdza się dla instytucji finansowej chroniącej biliony dolarów transakcji dziennie, po prostu nie zadziała w przypadku ochrony poczty elektronicznej prezydenta USA. Ochrona serwisu z grami wideo z milionami użytkowników jest zupełnie inna niż powstrzymanie aktorów ransomware przed kradzieżą kart kredytowych w Twojej ulubionej kawiarni. Mimo że wszyscy korzystamy z Internetu, każdy używa go w inny sposób, z różnymi technologiami i różną tolerancją na niezawodność i potencjalną utratę danych.
Dlatego bardzo się cieszę, że Nikki i Chris poprosili mnie o napisanie przedmowy do tej książki. Bez względu na to, jakie masz doświadczenie w zakresie bezpieczeństwa sieci, znajdziesz w tej książce doskonałe omówienie różnych aspektów zarządzania podatnościami. Przedstawia ona kilka różnych zalet i ograniczeń rozwiązań służących do pomiaru i eliminacji podatności w szerokim zakresie technologii. Obejmuje również różne rodzaje ram, które można wykorzystać do zrozumienia zasobów, ich podatności i danych dotyczących zgodności, co może być niezwykle przytłaczające. Niezależnie od tego, czy dopiero poznajesz pojęcie zarządzania podatnościami, czy też chcesz zarządzać zespołem korporacyjnym skupionym na zabezpieczeniu sieci dużego banku, ta książka zawiera odpowiednie dla Ciebie tematy.
_— RON GULA, PREZES GULA TECH ADVENTURES I WSPÓŁZAŁOŻYCIEL TENABLE NETWORK SECURITY_WPROWADZENIE
Żyjemy w świecie, który jest na niezliczone sposoby wspierany przez oprogramowanie. Ponad dekadę temu Marc Andreessen stwierdził, że „oprogramowanie pożera świat”, i rzeczywiście tak jest. Począwszy od naszych osobistych zajęć rekreacyjnych po infrastrukturę krytyczną i bezpieczeństwo narodowe prawie wszędzie wykorzystywane jest oprogramowanie. Oprogramowanie zasila nasze urządzenia medyczne, sieci telekomunikacyjne, stacje uzdatniania wody, instytucje edukacyjne — można by tu podać jeszcze wiele innych przykładów. Oznacza to, że oprogramowanie jest wszechobecne, ale wraz ze wzrostem wykorzystania i integracji oprogramowania w każdym aspekcie społeczeństwa wzrosły również podatności związane z naszymi systemami cyfrowymi. Przejawia się to w ogromnym poziomie ryzyka systemowego, które może mieć, ma i będzie miało wpływ na nasze codzienne życie.
Na Światowym Forum Ekonomicznym (World Economic Forum — WEF) stwierdzono, że pod koniec 2022 roku łącznie 60 procent globalnego PKB zależało od technologii cyfrowych. W 2023 roku WEF przeprowadziło ankietę, w której respondenci przewidywali „katastrofalny” incydent cybernetyczny w ciągu najbliższych dwóch lat. Zagrożenia związane z wykorzystywaniem podatności rosną z każdym rokiem, w połączeniu z łatwością korzystania ze złośliwych narzędzi do tworzenia i dystrybucji oprogramowania ransomware i złośliwego oprogramowania.
Od najwcześniejszych dni istnienia systemów komputerowych badacze i praktycy próbowali zaradzić podatnościom w systemach cyfrowych poprzez praktykowanie tak zwanego „zarządzania podatnościami”. Zgodnie z definicją amerykańskiego Narodowego Instytutu Standardów i Technologii (National Institute of Standards and Technology — NIST) podatność to „słabość systemu informatycznego, procedur bezpieczeństwa systemu, kontroli wewnętrznej lub implementacji, która może zostać wykorzystana lub uruchomiona przez źródło zagrożenia”.
Podatności systemów cyfrowych i możliwość ich wykorzystania zostały udokumentowane już w latach 70. w raporcie zatytułowanym _Security Controls for Computer Systems_, znanym również jako _Ware Report_, ponieważ pracownik RAND o nazwisku Willis Ware przewodniczył komitetowi przygotowującemu go dla Departamentu Obrony Stanów Zjednoczonych (DoD). Oprócz tego, że raport dotyczył podatności systemów, omówiono w nim potrzebę projektowania systemów z myślą o bezpieczeństwie w całym cyklu życia oprogramowania i rozwoju systemu. W 2023 roku amerykańska agencja CISA wydała wytyczne _Shifting the Balance of Cybersecurity Risk: Security-by-Design and Default_ _Principles_, w których wezwała producentów technologii do przejścia na tworzenie produktów bezpiecznych już na etapie projektowania.
Pomimo wezwań do tworzenia systemów bezpiecznych już od projektu i ponad pół wieku istnienia świadomości podatności w systemach cyfrowych i możliwości ich wykorzystania jako branża nadal zmagamy się z usuwaniem podatności w systemach cyfrowych, a także zapewnieniem, że bezpieczeństwo jest kluczową częścią projektowania i rozwoju systemu. Ponieważ nowoczesne środowiska cyfrowe stają się coraz bardziej złożone, a oprogramowanie coraz bardziej wszechobecne, organizacje mają trudności z nadążaniem z usuwaniem podatności, co prowadzi obecnie do nieprzewidzianych poziomów ryzyka systemowego w naszych cyfrowych ekosystemach.
Nastąpił ogromny wzrost publicznie ujawnionych i śledzonych podatności, przy czym godne uwagi źródła, takie jak Krajowa Baza Danych Podatności NIST (NVD), odnotowały wzrost liczby powszechnych podatności i naruszeń (CVE) z zaledwie kilkuset w latach 90. do ponad 190 tysięcy w 2022 roku. Podatności te są widoczne w oprogramowaniu, sprzęcie, bibliotekach i narzędziach (zarówno w rozwiązaniach open source, jak i gotowych). Ze względu na złożoność oprogramowania i aplikacji w różnych organizacjach sama liczba podatności jest trudna do śledzenia i usuwania.
Lista publicznie ujawnionych podatności rośnie z każdym rokiem, podobnie jak liczba niezałatanych podatności w organizacjach, choć te starają się usuwać je na bieżąco. W ankiecie przeprowadzonej w 2022 roku przez dostawcę zabezpieczeń Rezilion i Ponemon Institute 66 procent respondentów stwierdziło, że ma ponad 100 tysięcy podatności i że jest w stanie załatać tylko mniej niż połowę z nich. Inne badanie, opublikowane w 2022 roku przez dostawcę zabezpieczeń Qualys, wykazało, że nadal istnieje luka między średnim czasem usunięcia podatności (MTTR) przez organizacje a możliwościami ich wykorzystania przez złośliwe podmioty.
Do problemu rosnącej liczby publikacji podatności i wykorzystywania ich przez złośliwych aktorów przyczynia się fakt, że organizacje nie są w stanie zidentyfikować ważnych elementów szumu. Mimo że w 2022 roku opublikowano ponad 25 tysięcy znanych podatności, mniej niż 1 procent został wykorzystany przez złośliwych aktorów. Oznacza to, że organizacje poświęcają energię, wysiłek i zasoby na usuwanie podatności, które nigdy nie zostaną wykorzystane przez złośliwych aktorów, i próbują nadać sens i priorytet tym, które zostały lub prawdopodobnie zostaną wykorzystane.
Jak pokazujemy w całej książce, oprócz tego, że organizacje mają trudności z nadążaniem za łataniem podatności w oprogramowaniu i systemach, istnieje niezliczona ilość innych czynników, które komplikują zdolność organizacji do radzenia sobie z podatnościami. Obejmują one problemy związane z odpowiednią widocznością i inwentaryzacją zasobów, zapewnieniem bezpiecznych konfiguracji, aby zapobiec wykorzystaniu systemu przez złośliwych aktorów, wszechobecnym wykorzystaniem kodu innych firm i kodu open source, błędami konfiguracji oraz dodaniem czynników ludzkich do zarządzania podatnościami.
Złośliwi aktorzy coraz skuteczniej łączą podatności i wykorzystują wszechobecność oprogramowania we współczesnym społeczeństwie, napędzaną powszechnymi wysiłkami na rzecz transformacji cyfrowej. Wysiłki takie jak DevSecOps, które obiecują „przesunięcie bezpieczeństwa w lewo”, wiążą się z własnymi problemami, takimi jak błędne ustalenia nowoczesnych narzędzi do skanowania podatności, przeciążenie poznawcze często niedostatecznie obsadzonych zespołów ds. bezpieczeństwa oraz niedobór talentów w dziedzinie cyberbezpieczeństwa na całym świecie.
Biorąc pod uwagę powszechność łączenia podatności, transformacji cyfrowej, DevSecOps i obaw związanych z bezpieczeństwem łańcucha dostaw oprogramowania, można stwierdzić, że zarządzanie podatnościami jest teraz ważniejsze niż kiedykolwiek. Bez zaktualizowanego i nowoczesnego podejścia do obsługi podatności organizacje będą nadal zasypywane podatnościami z niewielkim kontekstem. Nasze podejście dotyczy środowisk chmurowych, dużych i małych programów rozwojowych oraz kombinacji wdrożeń hybrydowych i wielochmurowych. Podejście to skupia się nie tylko na technologii i metodykach zarządzania podatnościami, ale także na ludziach i organizacjach zaangażowanych w te działania.
A więc zaczynajmy.
Co zawiera ta książka?
Książka ta obejmuje następujące tematy:
Rozdział 1. „Zarządzanie aktywami”. W tym rozdziale omówiono podstawowe działania, takie jak zarządzanie aktywami, które obejmuje zarządzanie aktywami fizycznymi i mobilnymi, a także inwentaryzację zasobów oprogramowania i radzenie sobie ze złożonymi środowiskami chmurowymi, hybrydowymi i wielochmurowymi. Omówiono również narzędzia ułatwiające zarządzanie aktywami.
Rozdział 2. „Zarządzanie łataniem”. W tym rozdziale przedstawiono podstawy zarządzania łataniem, w tym zarówno zarządzanie ręczne, jak i zautomatyzowane, a także pokazano korzyści i kompromisy między nimi. Omówiono w nim zarządzanie poprawkami do oprogramowania, w tym oprogramowania typu open source, a także różne role i obowiązki związane z zarządzaniem poprawkami w różnych zespołach w organizacji.
Rozdział 3. „Bezpieczna konfiguracja”. Łatanie znanych podatności jest podstawą procesów zarządzania podatnościami, potrzebna jest jednak również bezpieczna konfiguracja. W tym rozdziale omówiono rolę przepisów i ram postepowania w bezpiecznych konfiguracjach, a także źródła takie jak publikacja NSA i CISA dotycząca dziesięciu głównych błędnych konfiguracji cyberbezpieczeństwa. Omówiono również wiodące w branży zasoby konfiguracyjne, takie jak CIS Benchmarks i DISA STIGs.
Rozdział 4. „Ciągłe zarządzanie podatnościami”. Zarządzanie podatnościami jest dalekie od chwilowego lub jednorazowego działania. W tym rozdziale przedstawiono pojęcie ciągłego zarządzania podatnościami i ciągłego monitorowania. Omówiono w nim zasoby takie jak kontrole CIS i NIST, które wiążą się z ciągłym zarządzaniem podatnościami oraz powiązanymi z nimi zadaniami i działaniami.
Rozdział 5. „Ocena podatności i identyfikacja oprogramowania”. Główną częścią zarządzania podatnościami jest identyfikacja oprogramowania i właściwe ustalanie priorytetów podatności. W tym rozdziale omawiamy obie te kwestie, w tym długotrwałe metodyki oceny podatności, a także pojawiające się zasoby informacji o podatnościach, takie jak Exploit Prediction Scoring System (EPSS) i katalog CISA Known Exploited Vulnerability (KEV), które pomagają organizacjom skuteczniej ustalać priorytety podatności.
Rozdział 6. „Zarządzanie bazą danych podatności i exploitów”. Podatności są przechwytywane i przechowywane w bazach podatności. W tym rozdziale omawiamy szeroko stosowane bazy danych podatności, jak np. NIST National Vulnerability Database (NVD), a także powstające bazy danych, np. Open Source Vulnerabilities (OSV), które zajmują się lukami w bazach danych takich jak NVD. Omawiamy również rolę baz danych exploitów i sposób, w jaki mogą one być wykorzystywane zarówno dla dobra, jak i na szkodę, w zależności od użytkownika.
Rozdział 7. „Łączenie podatności w łańcuch”. Często mówi się, że obrońcy myślą listami, a napastnicy wykresami. Wynika to z faktu, że napastnicy często starają się łączyć podatności w łańcuchy, aby przemieszczać się poziomo w środowiskach lub dotrzeć do wrażliwych zasobów. W tym rozdziale prezentujemy koncepcję łączenia podatności, a także podajemy przykłady i luki w branży, które dotyczą skupienia się na łączeniu podatności.
Rozdział 8. „Analiza zagrożeń związanych z podatnościami”. W tym rozdziale omówiono rolę analizy zagrożeń podatności i zaawansowane zagrożenia techniki, takie jak polowanie na zagrożenia. Omawiamy również integrację analizy zagrożeń z programami zarządzania podatnościami, nie tylko technologiami, ale także ludźmi i procesami.
Rozdział 9. „Chmura, DevSecOps i bezpieczeństwo łańcucha dostaw”. Współczesny krajobraz zagrożeń jest złożony i obejmuje chmurę, nacisk na DevSecOps i coraz częstsze ataki na łańcuch dostaw oprogramowania. W tym rozdziale zagłębiamy się w te tematy, w tym w kontenery w środowiskach wielochmurowych i hybrydowych, a także rolę oprogramowania open source i systemowe zagrożenia w całym łańcuchu dostaw oprogramowania.
Rozdział 10. „Czynnik ludzki w zarządzaniu podatnościami”. Większość rozmów na temat zarządzania podatnościami skupia się na aspektach technicznych, takich jak oprogramowanie i aplikacje. Jednak za całą tą technologią kryją się ludzie, działający w złożonych środowiskach społeczno-technicznych, którzy muszą sobie radzić z psychologicznymi czynnikami stresogennymi i wyzwaniami, takimi jak zmęczenie decyzjami i alarmami. W tym rozdziale omówiono ludzki element zarządzania podatnościami na zagrożenia, w tym wiodące badania na ten temat przeprowadzone przez jednego z autorów.
Rozdział 11. „Secure-by-design, czyli oprogramowanie bezpieczne już na etapie projektu”. U podstaw zarządzania podatnościami leży niewygodna prawda, że proces „łataj szybciej, naprawiaj szybciej” jest niesprawny. Organizacje nadal zmagają się z rosnącą liczbą podatności i niezabezpieczonymi produktami. W tym rozdziale omówiono dążenie do oprogramowania i produktów bezpiecznych już na etapie projektu/domyślnie, a także przedstawiono niektórych kluczowych graczy, którzy opowiadali się za tą zmianą paradygmatu. Omówiono w nim również niektóre wyzwania w związku z potrzebą dokonania tej fundamentalnej zmiany sposobu, w jaki działamy w cyfrowym świecie.
Rozdział 12: „Model dojrzałości zarządzania podatnościami”. Książkę kończymy rozdziałem poświęconym temu, jak rozpocząć ścieżkę tworzenia dojrzałego modelu zarządzania podatnościami. Omawiamy kluczowe zalecenia i kroki, od zarządzania zasobami po ciągłe monitorowanie i integrację czynników ludzkich. Mamy nadzieję, że dzięki temu czytelnicy będą mogli zmodernizować swoje programy zarządzania podatnościami i ostatecznie doprowadzić do zmniejszenia ryzyka dla organizacji.
Kto powinien przeczytać tę książkę?
Jak sugeruje tytuł książki, jest ona przeznaczona dla osób zainteresowanych zarządzaniem podatnościami, oprogramowaniem oraz systemami cyfrowymi i cyberfizycznymi. Jest ona odpowiednia dla różnych ról zawodowych, począwszy od kierownictwa (prezes, dyrektor technologiczny, dyrektor ds. bezpieczeństwa itp.), a skończywszy na praktykach bezpieczeństwa i oprogramowania oraz aspirujących początkujących, którzy chcą lepiej zrozumieć praktykę zarządzania podatnościami i ewoluujący krajobraz.
Jak skontaktować się z autorami
Autorzy będą wdzięczni za uwagi i pytania dotyczące tej książki! Wyślij e-mail do Chrisa Hughesa na adres [email protected]_, a do dr Nikki Robinson na adres [email protected]_.1. ZARZĄDZANIE AKTYWAMI
Zarządzanie aktywami to jeden z najważniejszych składników PROGRAMU ZARZĄDZANIA PODATNOŚCIAMI (ang. _vulnerability management program_ — VMP). Wśród podstawowych elementów składowych VMP najważniejsze jest to, aby zarządzanie aktywami było poprawne i pełne, zanim skupimy się na innych jego aspektach.
ZARZĄDZANIE AKTYWAMI to wykaz czy też spis całego sprzętu i oprogramowania w danym środowisku. Każde środowisko ma inny układ aktywów, obejmujący wszystko — od urządzeń mobilnych (np. laptopów i telefonów komórkowych) do bibliotek aplikacji i oprogramowania innych DOSTAWCÓW W FORMIE USŁUG (ang. _software-as-a service_ — SaaS). Bez wyczerpującego programu zarządzania zasobami organizacje mają ograniczoną możliwość stworzenia dojrzałego VMP mającego bezpieczną konfigurację, zarządzanie łatami i ciągły monitoring.
Na przestrzeni ostatnich dziesięciu lat zarządzanie aktywami mocno ewoluowało wraz z nadejściem infrastruktury w chmurze, zwiększonym wykorzystywaniem SaaS, rosnącym wykładniczo użyciem oprogramowania open source oraz dużymi i złożonymi środowiskami deweloperskimi. Wiele lat temu zarządzanie aktywami mogło w swej prostocie sprowadzać się do arkusza z nazwami aktywów, numerami znaczników i ewentualnie do informacji o właścicielu lub adresie IP. Rejestry sprzętu i oprogramowania były przechowywane oddzielnie i potencjalnie zarządzał nimi ten sam administrator IT. Jednak wraz z rosnącym wykorzystaniem infrastruktury w chmurze jako INFRASTRUKTURY JAKO USŁUGI (ang. _infrastructure-as-a-service_ — IaaS), PLATFORMY JAKO USŁUGI (ang. _platform-as-a-service_ — PaaS) lub Saas tradycyjne metody zarządzania aktywami przestały być już opłacalne. Wykorzystanie arkusza kalkulacyjnego do złożonych i dynamicznych aktywów nie daje możliwości zarządzania nimi, a zarządzanie dostępnymi i aktualizowanymi informacjami i przechowywanie ich jest w ten sposób niewykonalne.
Tradycyjne zarządzanie składnikami podatności może obecnie nie osiągnąć dojrzałości przy ręcznych lub niepełnych spisach aktywów. Zarządzanie dynamicznymi aktywami takimi jak kontenery, które są przeznaczone do działania online i mogą być usuwane w dowolnym momencie, jest obecnie coraz trudniejsze. Te rodzaje aktywów wymagają programu dynamicznego zarządzania aktywami — takiego, który może być szybko aktualizowany i skalowany dla dużych projektów deweloperskich. Biblioteka aktywów nie może być używana wyłącznie do zarządzania urządzeniami mobilnymi lub aktywami sprzętowymi, lecz musi mieć możliwość przechowywania zaktualizowanej informacji na temat efemerycznych aplikacji i narzędzi.
Bez nowoczesnego podejścia do zarządzania aktywami organizacje mają ograniczoną widzialność sprzętu i oprogramowania używanych przez pracowników, co może mieć kilka nakładających się skutków. Przykładowo, bez wiedzy o laptopie nie jest możliwe właściwe monitorowanie zainstalowanego oprogramowania pod kątem łatek, jeśli sprzęt jest w posiadaniu pracownika. Podobnie jest, jeśli chodzi o zgodność z polityką firmy. A jeśli organizacja nie może zobaczyć, jakie oprogramowanie jest zainstalowane w poszczególnych systemach, nie może znać wielu elementów podatnych, potencjalnej powierzchni ataku ani wpływu, jaki oprogramowanie może mieć na inne systemy.
Inne ograniczenia niedojrzałego zarządzania aktywami to są „nieznane niewiadome”. Jeśli istnieją aktywa sprzętowe lub programowe, które nie są skutecznie zarządzane lub widziane przez personel działu IT, organizacje nie znają zakresu podatności, nieuchronnego ryzyka ani wzajemnych połączeń urządzeń i aplikacji. Ograniczenia sprawiają, że nie jest możliwe efektywne ustalenie priorytetów i korygowanie podatności. To powoduje, że trudno jest określić, czy aplikacje mają właściwy poziom łat, czy wersja aplikacji zbliża się do końca jej wsparcia i czy istnieją wyjątkowe podatności lub braki w konfiguracji, które mogą prowadzić do cyberataków takich jak rozproszona odmowa usług (ataki DDOS), szkodliwe oprogramowanie (malware) lub żądania okupu (ransomware).
Zarządzanie aktywami można przeprowadzić na wiele różnych sposobów. Organizacje wykorzystują oprogramowanie operacyjne działu IT, narzędzia do skanowania podatności, inwentarzy w chmurze i wiele innych programów do zarządzania konfiguracją, jak np. ServiceNow ( _https://www.servicenow.com/_ ). Ten rodzaj oprogramowania może nie tylko śledzić aktywa, lecz także powiązać zgłoszenia oraz bieżące zarządzanie tymi urządzeniami z właścicielem systemu. Mniejsze organizacje mogą nadal ręcznie zarządzać aktywami, co ogranicza dojrzałość i możliwości VMP. W tym rozdziale omawiamy powszechne ograniczenia narzędzi i procesów zarządzania aktywami, możliwy wpływ niedojrzałego programu zarządzania aktywami i to, co organizacja może zrobić, aby wprowadzić nowoczesne podejście do zarządzania aktywami.
Fizyczne i mobilne zarządzanie aktywami
Zarządzanie aktywami w tradycyjnych centrach danych obejmuje składniki fizyczne w szafach serwerowych — np. urządzenia sieciowe, serwery, zarządzanie mocą i inne fizyczne urządzenia w organizacji. Jednak organizacje przeszły na bardziej cyfrową siłę roboczą, wykorzystując wiele urządzeń mobilnych pracowników. Jeden pracownik może mieć tablet, laptop i smartfon, a do współpracy wykorzystywać przede wszystkim aplikacje online, zamiast pracować wyłącznie na fizycznym komputerze znajdującym się w biurze.
Wiele organizacji przenosi się do środowisk pracy hybrydowej, gdzie pracownicy pracują na zmianę w biurze organizacji lub w domu albo innym biurze poza firmą. Ten rodzaj środowiska pracy komplikuje zarządzanie urządzeniami z uwagi na to, że mogą być one połączone z wirtualną siecią prywatną organizacji (VPN) lub nie, a potencjalnie z aktywami w chmurze i serwerami. Taki układ zwiększył wyzwania związane z zarządzaniem urządzeniami mobilnymi i śledzeniem ich.
W nowoczesnych organizacjach zarządzanie tymi urządzeniami mobilnymi wymaga rozwiązania zarządzania aktywami, które będzie obsługiwać systemy operacyjne (OS) oraz aplikacje wymagane do obsługi współpracy online. Narzędzia mobilne obejmują oprogramowanie do zarządzania aktywami i inwentarzem, a także zarządzania konfiguracją, zwykle realizowanego za pomocą rozwiązania MDM (ang. _mobile device management_ ). Narzędzie to zapewnia konsole zarządzania do katalogowania każdego urządzenia mobilnego i przypisuje reguły i konfigurację zabezpieczeń określone przez organizację.
Kilka rozwiązań SaaS jest także dostępnych jako narzędzia dostarczane przez operatora komórkowego. Na przykład rozwiązania mobilne firmy Apple (jak iPhone, iPad) mają swoje własne rozwiązania zarządzania aktywami, takie jak oprogramowanie Jaml. Jednak inne urządzenia lub aplikacje mogą być zarządzane za pomocą rozwiązań MDM, takich jak Miradore i Citrix Endpoint Management.
Ponieważ większość organizacji odchodzi od centrów danych znajdujących się w firmie, coraz mniej serwerów i urządzeń sieciowych wymaga zarządzania aktywami. Wraz z nadejściem chmury coraz więcej organizacji migruje ze swoimi fizycznymi aktywami do infrastruktury w chmurze i w większym stopniu wykorzystuje efemeryczne serwery jak kontenery. Jednak centra danych znajdujące się w firmie nadal wymagają rozwiązania związanego z zarządzaniem aktywami, które zapewnia pełną widoczność wszystkich systemów. Nie chodzi tylko o zabezpieczenia — muszą one także zarządzać systemami i sprawić, aby poprawnie działały online bez awarii sprzętowych. Wszystkie fizyczne aktywa mogą mieć wskaźniki ostrzegające przed cyberatakami, a jeśli nie są właściwie monitorowane, organizacja może nie mieć krytycznych danych do określania ryzyka.
Podczas gdy zarządzanie fizycznym ryzykiem skupia się zwykle na urządzeniach mobilnych, coraz więcej wysiłków w dużych organizacjach „wraca do pracy”. Oznacza to, że aktywa fizyczne i MDM mogą mieć coraz większą złożoność i zawierać mieszankę naszych własnych urządzeń (ang. _bring-your-own-device_ — BYOD) i aktywów będących własnością korporacji. Taka złożoność może wymagać integracji wielu produktów lub użycia dwóch oddzielnych aplikacji do zarządzania fizycznymi aktywami albo więcej ustawień konfiguracyjnych na laptopach i tabletach. Ponieważ większość organizacji korzysta z narzędzi do inwentaryzacji oraz oddzielnego narzędzia do zarządzania konfiguracją, taka złożoność dodaje właścicielom systemu kolejną warstwę do oceny i zarządzania aktywami w celu uzyskania spójności.
Aktywa IoT konsumenta
Inna kategorią aktywów, która stała się poważnym ryzykiem dla organizacji, są urządzenia Internetu rzeczy (ang. _Internet od Things_ — IoT). Wraz ze wzajemnymi połączeniami urządzeń IoT może obejmować cokolwiek — od termostatu bieżni, urządzenia automatyki domowej po urządzenia osobiste takie jak smartwatche. Ponieważ wiele organizacji, zwłaszcza opieki zdrowotnej i medycznej, wykorzystuje Wi-Fi, czyli połączenia bezprzewodowe, pracownicy mogą mieć możliwość łączenia swoich osobistych urządzeń z siecią lokalną.
Zezwolenie na dostęp do sieci wszystkich tych wrażliwych urządzeń IoT powoduje wiele obaw. Amerykański instytut standaryzacji NIST (National Institute of Standards and Technology) opublikował przewodnik dla konsumentów dotyczący ryzyka i potencjalnych obaw o bezpieczeństwo związanych z urządzeniami IoT. Przewodnik NIRT pod tytułem _IoT Cybersecurity Criteria for Consumer Labeling Program_ został wydany na początku 2022 roku, prezentując szczegóły dotyczące rosnącej potrzeby informacji dla konsumentów na temat cyberbezpieczeństwa związanego z ryzykiem ze strony urządzeń IoT. Rząd Bidena i Harris wypuścił ostatnio dodatkowe zalecenia związane z etykietowaniem produktów, aby ułatwić konsumentom zrozumienie ryzyka związanego z produktami ( _https://www.presidency.ucsb.edu/documents/white-house-press-release-biden-harris-administration-announces-cybersecurity-labeling_ ).
W artykule Mary K. Pirat w Tech Target, pod tytułem _Top 10 security threats and risks to_ _prioritize_ , na stronie _www.techtarget.com/iotagenda/tip/5-IoT-security-threats-to-prioritize_ , podano różne sposoby, w jakie urządzenia IoT nogą stwarzać ryzyko dla organizacji. Jednym z największych zagrożeń dla wszystkich organizacji, które uwypuklono w tym artykule, jest zwiększona powierzchnia ataku. Podobnie jak w przypadku urządzeń mobilnych i rozszerzonej telepracy lub mobilnych pracowników, im więcej urządzeń może połączyć się z siecią, tym większe jest ryzyko i możliwe wektory ataku. Organizacje muszą mieć odpowiednie pojęcie o tym, jakie urządzenia IoT mogą znajdować się w ich sieci, wykorzystując w tym celu skanowanie sieci lub sniffing (węszenie), aby wykryć wrogie lub niespodziewane urządzenia IoT. SNIFFING to technika wykorzystywana przez hakerów do wykrywania, czy istnieją niezabezpieczone urządzenia lub systemy, które mogą być możliwe do eksploatacji. Istnieje wiele sposobów wykrywania ataków na środowisko — są one szerzej omówione w następnych rozdziałach.
Aktywa programistyczne
Inwentarze oprogramowania stają się coraz ważniejszym tematem. Wprawdzie zagadnienie to jest szerzej omawiane w następnym rozdziale, jednak ważne jest, aby powiedzieć tu o podstawach. Ostatnie ataki i luki _zero-day_ wymierzone w firmy SolarWinds, Log4J i MOVEit były istotnymi czynnikami motywującymi zrozumienie krajobrazu oprogramowania i powierzchni ataku. Aby zrozumieć duże powierzchnie ataku, organizacje muszą katalogować i inwentaryzować wykorzystywane przez siebie narzędzia programistyczne, biblioteki i zależności. LUKA _ZERO-DAY_ stanowi podatność w oprogramowaniu lub sprzęcie, która nie była wcześniej znana, a może być poważnie wykorzystana.
Bez odpowiedniego zinwentaryzowania oprogramowania organizacje mogą usilnie próbować znaleźć w swoich aplikacjach luki _zero-day_ , co zostawia im niewiele czasu na naprawę, dając z kolei napastnikom więcej czasu na wykorzystanie podatności. Gdy wiele organizacji wykorzystuje większe i bardziej skomplikowane środowiska deweloperskie, wykrywanie aktywów oprogramowania i ciągłe monitorowanie stają się kluczowymi aspektami zarządzania ryzykiem.
Jeśli przykładowo organizacja ma ograniczony wgląd w to, jakie biblioteki deweloperzy dodają, usuwają, łatają lub nie łatają, jej zespół ds. zabezpieczeń nie będzie mógł ocenić ryzyka i ustalić priorytetów łatania i naprawy. Jeśli jakieś biblioteki lub zależności pozostaną niewykryte lub nie zostaną automatycznie przekazane do narzędzia inwentaryzacji, organizacja będzie nieświadoma liczby i wagi istniejących podatności.
Inną obawą jest możliwość wykorzystywania oprogramowania open source, które może nie być regularnie łatane i konserwowane. Im większe jest środowisko deweloperskie, tym większa jest możliwość istnienia nieznanych i niewykrytych podatności i braków bezpiecznych konfiguracji.
Zarządzanie aktywami w chmurze
Wraz z transformacją cyfrową, zwinnym (ang. _agile_ ) tworzeniem oprogramowania oraz rosnącym ukierunkowaniem na sztuczną inteligencję (AI) przejście systemu do chmury stanowi integralny krok zarządzania infrastrukturą i złożonymi środowiskami deweloperskimi. Coraz więcej organizacji rozważa środowiska wielochmurowe lub hybrydowe wykorzystujące dwóch dostawców chmury lub ewentualnie wdrożenie chmury prywatnej i publicznej u tego samego dostawcy. Środowiska wielochmurowe pozwalają na osiągnięcie większej odporności i skalowalności, podczas gdy opcje chmury prywatnej i publicznej (czyli chmura hybrydowa) pozwalają organizacji na utrzymanie określonych aktywów oddzielonych od publicznej infrastruktury w chmurze.
Rysunek 1.1 pokazuje proste wyjaśnienie różnic między środowiskami hybrydowym i wielochmurowym. Układ hybrydowy chmury wykorzystuje połączenie prywatnej i publicznej opcji chmury, ale zwykle u jednego dostawcy usługi chmurowej (ang. _cloud service provider_ — CSP). Rozwiązanie wielochmurowe wykorzystuje natomiast dwóch lub więcej CSP jako hosty infrastruktury.
RYSUNEK 1.1. Środowisko hybrydowe a wielochmurowe
Środowiska wielochmurowe
W niektórych środowiskach wielochmurowych organizacja może potrzebować wielu dostawców chmury. Przykładem może tu być potrzeba uruchamiania prac produkcyjnych i nieprodukcyjnych w jednym środowisku chmury przy wykorzystaniu drugiej chmury do odporności i szybkiego transferu w przypadku awarii sieciowej lub regionalnej u jednego z dostawców. Innym przykładem jest uruchomienie prac produkcyjnych i nieprodukcyjnych w jednym środowisku chmurowym oraz przechowywanie kopii zapasowych i magazynów długoterminowych w innym środowisku chmury na wypadek konieczności odzyskiwania utraconych danych.
Niestety korzystanie z wielu dostawców chmury komplikuje strategię zarządzania aktywami. Jedną z największych obaw podczas korzystania z wielu dostawców chmury w strategii wielochmurowej jest to, że zbieranie, automatyzacja i śledzenie aktywów w obu środowiskach może wymagać wielu różnych narzędzi. Coraz więcej nowoczesnych organizacji korzysta ze strategii wielochmurowej i narzędzi innych firm do synchronizacji danych między tymi odmiennymi środowiskami. Narzędzia takie jak CloudSphere mają na celu rozwiązywanie problemów dotyczących bezpieczeństwa konfiguracji i inwentarza poprzez zbieranie i utrzymywanie danych o aktywach. Jednak oznacza to, że każde środowisko chmury musi mieć otwarte różne porty i tworzyć konta usługowe w chmurze do zarządzania informacjami. Niezwykle łatwo stracić z pola widzenia efemeryczne systemy każdego środowiska, jeśli nie będą one miały kopii lustrzanej.
Hybrydowe środowiska chmury
Hybrydowe rozwiązanie w chmurze może być potencjalnie wykorzystywane z podobnych powodów, ale jego architektura jest całkiem inna. Chmura hybrydowa wykorzystuje środowiska prywatne i publiczne. Organizacja może na przykład wykorzystywać tę strategię do przechowywania określonych danych i aktywów o dużym znaczeniu w chmurze prywatnej a tych o mniejszym znaczeniu — w tańszym środowisku chmury publicznej. Może to na kilka sposobów skomplikować zarządzanie zasobami, ale może być też korzystne dla organizacji poszukującej w dłuższym czasie strategii kontroli wydatków i oszczędności. Środowiska hybrydowe w chmurze same w sobie mogą być świetnymi rozwiązaniami dla organizacji, które chcą przechowywać swoją własność intelektualną, identyfikowalne dane osobowe oraz inne wrażliwe dane w chmurze prywatnej, natomiast inne elementy związane z pracą, mniej krytyczne dla biznesu, w środowisku chmury publicznej.
Rysunek 1.2 przedstawia różne warstwy w ramach organizacji, dla których trzeba zbudować infrastrukturę IT. Górna warstwa obejmuje wszystko od platformy do zarządzania chmurą i infrastrukturą, a także ogólną architekturę sieciową. Warstwa pośrednia obejmuje działania aplikacji w infrastrukturze, środowisko deweloperskie oraz główne komponenty zabezpieczeń, które stale monitorują środowisko. Suwerenne środowisko chmury jest tym, w którym dostawca przechowuje wszystkie dane organizacji w jej własnym kraju.
RYSUNEK 1.2. Warstwy infrastruktury IT
Rysunek 1.2 pokazuje zróżnicowane warstwy w usługach platformy w środowiskach chmury. W górnej warstwie są usługi takie jak obliczenia w chmurze i brzegowe, interfejsy zarządzania, a także platforma aplikacji. Warstwy pośrednie składają się ze środowisk deweloperskich, z działań w infrastrukturze, a także największych komponentów zabezpieczeń. Warstwa chmury stanowi sama w sobie platformę, niezależnie od tego, czy są to usługi sieciowe Amazona (AWS, Amazon Web Services), czy Oracle’a.
Jedną z głównych obaw związanych z korzystaniem z rozwiązań hybrydowych chmury są ewentualne ograniczenia między prywatnym a publicznym środowiskiem chmury. Ograniczenia te obejmują zwykłą złożoność zarządzania dwoma oddzielnymi środowiskami chmury, a także składniki zabezpieczeń i ręczną implementację tego samego sterowania. Innym rozwiązaniem może być uruchomienie tego samego narzędzia w obu środowiskach, aby posegmentować sieci i zagregować dane w innych miejscach. Jednak zgoda na dostęp do chmury prywatnej z chmury publicznej może zwiększyć ryzyko naruszenia zabezpieczeń między tymi dwoma środowiskami.
Oprogramowanie innych firm oraz oprogramowanie open source (OSS)
Często tradycyjne narzędzia zarządzania aktywami nie biorą pod uwagę oprogramowania innych firm ani oprogramowania open source (OSS) używanego w nowoczesnych organizacjach. Ale rozbudowane wykorzystanie OSS powoduje skomplikowane zarządzanie aktywami, procesami dla bibliotek oprogramowania oraz problemy z możliwością wyznaczenia ryzyka.
Jak to pokazano na rysunku 1.3, oprogramowanie używane jest w wielu warstwach przedsiębiorstwa. Począwszy od warstwy biznesowej aplikacje takie jak Java i Log4j (tj. komponenty OSS) budują podstawy dla środowisk deweloperskich. Może być potrzebne dodatkowe oprogramowanie w warstwach prezentacji i usług w celu zintegrowania ze sobą i wzajemnego skomunikowania, aby zbudować złożone aplikacje.
Na rysunku 1.3 widać zarys różnych warstw, które współdziałają ze sobą w całym przedsiębiorstwie. Warstwa biznesowa stanowi szkielet dla pozostałych warstw i ma ważne powiązanie ze wszystkimi innymi środowiskami przedsiębiorstwa — od warstwy danych i trwałości, która zawiera bazy danych, do warstwy infrastruktury wykorzystującej komponenty Red Hat i OS. Każdy fragment tej macierzy współdziała, tworząc wszechstronną platformę wspierającą funkcje biznesowe.
Ze względu na zwiększone wykorzystanie OSS organizacje doświadczają zależności i zawiłości działania OSS w złożonych i dużych środowiskach aplikacji. Wielu deweloperów wykorzystuje OSS ze względu na średni czas dostawy, co oznacza, że mogą poświęcić mniej czasu, pisząc ponownie kod, który już istnieje, za pomocą narzędzi stworzonych przez innych deweloperów. Redukowanie czasu spędzonego na kodowaniu i zapewnienie swoim aplikacjom pewnej spójności pozwalają deweloperom poświęcić czas na bardziej złożone i zniuansowane cykle rozwojowe. Jednak wraz ze zwiększonym wykorzystaniem OSS pojawia się zarazem potrzeba skatalogowania i zrozumienia rodzajów bibliotek i narzędzi wykorzystywanych w obrębie aplikacji.
RYSUNEK 1.3. Różne warstwy przedsiębiorstwa
Oprogramowanie innych firm (i związane z nim ryzyko)
Jednym z elementów, który trudniej zebrać i utrzymywać w wykazie inwentarza, jest liczba zewnętrznych firm i aplikacji, wykonawców, produktów SaaS i innego oprogramowania zewnętrznego. Na przykład organizacja może zdecydować się na użytkowanie zapory sieciowej od usługodawcy z zewnątrz, zamiast uruchamiać własne urządzenia tego typu i własną konfigurację sieci, ze względu na brak wykwalifikowanego personelu i innych zasobów do zarządzania takimi aktywami.
Innym przykładem jest sytuacja, w której organizacja zleca firmie zewnętrznej prowadzenie księgowości lub pomocy technicznej IT. Firmy zewnętrzne muszą mieć dostęp do zasobów korporacji, co potencjalnie wymaga poświadczeń do domeny lub otwartych portów bądź dostęp do SaaS i infrastruktury organizacji. Wykonawca zewnętrzny może mieć urządzenia mobilne wymagające dostępu do środowiska, co zwiększa potencjalną powierzchnię ataku.
Od początku trzeciej dekady XXI wieku złośliwi aktorzy wykorzystywali otwarty dostęp do konta lub infrastruktury aplikacji innych firm, aby uzyskać dostęp do tajemnic korporacyjnych. Katalogowanie tych zewnętrznych aplikacji można wykonać za pomocą różnorodnych narzędzi i metod, ale mogą być wykrywane też przez narzędzia do skanowania podatności takie jak Tenable lub Qualys. Dlatego istotne dla organizacji jest określenie, jakie metody są najlepsze do wykrywania i monitorowania w środowisku tych aplikacji innych firm, aby chronić się przed ryzykiem.
Uwzględnianie oprogramowania open source
Statyczne listy nie uchwycą zmieniających się wersji, poprawek ani usuwania oprogramowania open source (OSS) w danym środowisku. Organizacje muszą przejść na dynamiczne odkrywanie i kategoryzację aktywów ze względu na możliwość popełniania przez ludzi błędów i pomijane aktywa w procesie ręcznym. Wszelkie pominięte aktywa to możliwy punkt wejścia dla napastnika jako możliwa do wykorzystania podatność lub wadliwa konfiguracja. Proces powinien zostać w jak największym stopniu zautomatyzowany — pozwalając deweloperom na spójną zmianę ich aplikacji bez narażania się na poważne zawirowania w działaniach związanych z zarządzaniem konfiguracją.
Wykorzystanie GitHuba lub innego narzędzia open source (stworzonego dla deweloperów) jest możliwym rozwiązaniem dla dynamicznej inwentaryzacji aplikacji OSS. Zaleca się korzystanie z repozytorium open source, które jest już używane przez deweloperów, niezależnie od tego, czy jest to GitHub, GitLab, czy inna platforma. Najważniejszym elementem każdej z tych opcji jest posiadanie spójnego procesu znanego wszystkim deweloperom.
Dokumentacja i standardowa procedura działania (ang. _standard operating procedure_ — SOP) zarządzania inwentarzem w OSS jest tak samo ważna jak narzędzia, które realizują to zarządzanie. Te opcje pozwalające deweloperom na zarządzanie OSS są zwykle niezależne od platformy i dają dodatkowe funkcjonalności w porównaniu ze standardowymi systemami zarządzania inwentarzem w chmurze. Istnieje także kilka opcji „do kupienia”, a organizacje powinny dokładnie rozważyć swoje indywidualne potrzeby _przed_ wyborem produktu.
Inwentaryzacja aktywów lokalnych i w chmurze