Cyberbezpieczeństwo : Zrozumienie łańcucha zabijania cyberbezpieczeństwa

Dowiedziałeś się o procesie reagowania na incydenty oraz o tym, jak wpisuje się on w ogólną poprawę stanu bezpieczeństwa firmy. Teraz nadszedł czas, aby zacząć myśleć jak napastnik i zrozumieć powody, motywację i kroki wykonania ataku. Nazywamy to łańcuchem zabijania cyberbezpieczeństwa, który pokrótce omówiliśmy wcześniej. Obecnie donosi się, że najbardziej zaawansowane cyberataki obejmują włamania do sieci celu, które trwają długo, zanim wyrządzą szkody lub zostaną wykryte. To ujawnia wyjątkową cechę współczesnych napastników: mają zdumiewającą zdolność pozostawania niewykrytym, dopóki nie nadejdzie odpowiedni czas. Oznacza to, że działają na dobrze ustrukturyzowanych i zaplanowanych planach. Precyzja ich ataków została zbadana i ujawniła, że ​​większość cyberprzestępców wykorzystuje serię podobnych faz, aby przeprowadzić udane ataki. Aby poprawić swój stan bezpieczeństwa, musisz upewnić się, że wszystkie fazy łańcucha zabijania cyberbezpieczeństwa są uwzględnione z perspektywy ochrony i wykrywania. Ale jedynym sposobem, aby to zrobić, jest upewnienie się, że rozumiesz, jak działa każda faza, sposób myślenia napastnika i opłaty pobierane w każdej fazie. Tu omówimy następujące tematy:

* Zwiad zewnętrzny

* Narażanie systemu

* Ruch boczny

* Eskalacja uprawnień

* Zakończenie misji

ZNACZENIE ZARZĄDZANIA ŁATKAMI.

Z punktu widzenia bezpieczeństwa łatki są najczęściej interesujące, ponieważ łagodzą luki w oprogramowaniu; zastosowanie łat eliminujących te podatności znacznie ogranicza możliwości wykorzystania. Ponadto łatki są zwykle najskuteczniejszym sposobem ograniczania luk w oprogramowaniu i często są jedynym w pełni skutecznym rozwiązaniem. Czasami istnieją alternatywy dla poprawek, takie jak tymczasowe obejścia obejmujące oprogramowanie lub rekonfigurację kontroli bezpieczeństwa, ale te obejścia często negatywnie wpływają na funkcjonalność. Łatki służą innym celom niż tylko naprawianie wad oprogramowania; mogą również dodawać nowe funkcje do oprogramowania i oprogramowania układowego, w tym funkcje bezpieczeństwa. Nowe funkcje można również dodawać poprzez aktualizacje, które wprowadzają oprogramowanie lub oprogramowanie układowe do nowszej wersji w znacznie szerszym zakresie niż tylko nałożenie poprawki. Uaktualnienia mogą również rozwiązać problemy z zabezpieczeniami i funkcjonalnością w poprzednich wersjach oprogramowania i oprogramowania układowego. Ponadto dostawcy często przestają wspierać starsze wersje swoich produktów, co obejmuje zaprzestanie wydawania łatek usuwających nowe luki w zabezpieczeniach, przez co z czasem starsze wersje stają się mniej bezpieczne. Aktualizacje są niezbędne, aby takie produkty otrzymały obsługiwaną wersję, która jest załatana. Istnieje kilka wyzwań, które komplikują zarządzanie poprawkami. Jeśli organizacje nie sprostają tym wyzwaniom, nie będą w stanie skutecznie i wydajnie łatać systemów, co prowadzi do łatwych do uniknięcia kompromisów. Organizacje, które mogą zminimalizować czas poświęcony na instalowanie poprawek, mogą wykorzystać te zasoby do rozwiązywania innych problemów związanych z bezpieczeństwem. Już wiele organizacji w dużej mierze zoperacjonalizowało zarządzanie poprawkami, czyniąc je bardziej podstawową funkcją IT niż częścią bezpieczeństwa. Jednak nadal ważne jest, aby wszystkie organizacje starannie rozważyły ​​zarządzanie poprawkami w kontekście bezpieczeństwa, ponieważ zarządzanie poprawkami jest tak ważne dla osiągnięcia i utrzymania solidnego bezpieczeństwa. Zarządzanie poprawkami jest wymagane przez różne struktury zgodności zabezpieczeń, mandaty i inne zasady. Na przykład specjalna publikacja NIST (SP) 800-532 wymaga kontroli bezpieczeństwa SI-2, FlawRemediation, która obejmuje instalowanie istotnych dla bezpieczeństwa poprawek oprogramowania i oprogramowania sprzętowego, testowanie poprawek przed ich zainstalowaniem oraz włączanie poprawek do procesów zarządzania konfiguracją organizacji. Innym przykładem jest standard Payment Card Industry (PCI) Data Security Standard (DSS)3, który wymaga zainstalowania najnowszych poprawek i określa maksymalny czas instalacji najbardziej krytycznych poprawek.

Cyberbezpieczeństwo : Streszczenie

Na razie dowiedziałeś się o procesie reagowania na incydenty oraz o tym, jak wpisuje się on w ogólny cel poprawy stanu bezpieczeństwa. Dowiedziałeś się również, jak ważne jest posiadanie reakcji na incydenty, aby szybko identyfikować i reagować na incydenty związane z bezpieczeństwem. Planując każdą fazę cyklu życia odpowiedzi na incydent, tworzysz spójny proces, który można zastosować w całej organizacji. Podstawa planu reagowania na incydenty jest taka sama dla różnych branż, a oprócz tego można uwzględnić niestandardowe obszary, które są istotne dla Twojej firmy. Zetknąłeś się również z kluczowymi aspektami obsługi incydentu i znaczeniem działań po incydencie – które obejmują pełną dokumentację wyciągniętych wniosków – oraz wykorzystania tych informacji jako danych wejściowych do poprawy ogólnego procesu. Na koniec poznałeś podstawy reagowania na incydenty w chmurze i tego, jak może to wpłynąć na Twój bieżący proces. Teraz  zrozumiesz sposób myślenia napastnika, różne etapy ataku oraz to, co zwykle ma miejsce w każdej z tych faz. Jest to ważna koncepcja, biorąc pod uwagę, że ćwiczenia ataku i obrony będą wykorzystywać łańcuch zabijania cyberbezpieczeństwa jako podstawę.

ZARZĄDZANIE POPRAWKAMI DO OPROGRAMOWANIA I LUKAMI

Luki w zabezpieczeniach to luki, które mogą zostać wykorzystane przez złośliwą jednostkę w celu uzyskania większego dostępu lub przywilejów niż jest to dozwolone w systemie komputerowym. Poprawki to dodatkowe fragmenty kodu opracowane w celu rozwiązania problemów (powszechnie nazywanych „błędami”) w oprogramowaniu. Łatki korygują problemy z bezpieczeństwem i funkcjonalnością oprogramowania i oprogramowania układowego. Zarządzanie poprawkami to proces identyfikacji, pozyskiwania, instalowania i weryfikowania poprawek dla produktów i systemów. Zarządzanie poprawkami to praktyka bezpieczeństwa mająca na celu proaktywne zapobieganie wykorzystywaniu luk w zabezpieczeniach IT istniejących w organizacji. Oczekiwanym rezultatem jest skrócenie czasu i pieniędzy przeznaczanych na radzenie sobie z lukami i wykorzystywaniem tych luk. Proaktywne zarządzanie podatnościami systemów zmniejszy lub wyeliminuje możliwość wykorzystania i będzie wymagało znacznie mniej czasu i wysiłku niż reagowanie po wystąpieniu eksploatacji. Ten rozdział ma na celu pomóc organizacjom we wdrażaniu programów naprawiających poprawki i luki w zabezpieczeniach. Najpierw wyjaśnia znaczenie zarządzania poprawkami, a następnie omawia wyzwania związane z zarządzaniem poprawkami. Następnie rozdział zawiera przegląd technologii zarządzania poprawkami w przedsiębiorstwie i zalecenia dotyczące ich użycia. Ma również na celu poinformowanie czytelnika o możliwych miarach i metrykach zarządzania poprawkami w przedsiębiorstwie.

Cyberbezpieczeństwo : Aktualizacja procesu IR w celu uwzględnienia chmury

W idealnym przypadku powinieneś mieć jeden pojedynczy proces reagowania na incydenty, który obejmuje zarówno główne scenariusze lokalne, jak i chmurowe. Oznacza to, że będziesz musiał zaktualizować swój bieżący proces, aby uwzględnić wszystkie istotne informacje związane z chmurą. Upewnij się, że przeglądasz cały cykl życia IR, aby uwzględnić aspekty związane z przetwarzaniem w chmurze. Na przykład podczas przygotowań musisz zaktualizować listę kontaktów, aby zawierała informacje kontaktowe dostawcy chmury, proces dyżurowania i tak dalej. To samo dotyczy innych faz:

* Wykrywanie: w zależności od modelu chmury, którego używasz, chcesz uwzględnić rozwiązanie dostawcy chmury do wykrywania, aby pomóc ci podczas dochodzenia.

* Ograniczanie: Sprawdź ponownie możliwości dostawcy chmury, aby wyizolować incydent na wypadek jego wystąpienia, co również będzie się różnić w zależności od używanego modelu chmury. Na przykład, jeśli masz zhakowaną maszynę wirtualną w chmurze, możesz chcieć odizolować tę maszynę wirtualną od innych w innej sieci wirtualnej i tymczasowo zablokować dostęp z zewnątrz.

Hakowanie

Kiedy pojawiają się błędy i problemy, hakerstwo – zarówno wewnętrzne, jak i zewnętrzne – powinno być brane pod uwagę i poszukiwane poprzez przeglądanie dzienników, kto pracował nad oprogramowaniem i kiedy ta praca została wykonana. Menedżerowie powinni być w stanie wykryć użycie legalnych identyfikatorów, gdy zaangażowane osoby były na wakacjach, były chore lub nie były dostępne do zalogowania się z innych powodów. Archiwizacja dzienników i ich odzyskiwanie jest coraz bardziej krytyczną funkcją, poza wymogami regulacyjnymi SOX, HIPAA, GLBA i tak dalej. Dzienniki są często używane do:

* Działania związane z reagowaniem na incydenty, w szczególności przy ustalaniu:

* Jeśli doszło do incydentu

* Kiedy doszło do incydentu

* Co wydarzyło się przed i po podejrzeniu wystąpienia incydentu

* Badania; może to być przegląd możliwości wydajności lub problemów ze sprzętem, oprogramowaniem lub siecią

Aby zapewnić dostępność dzienników w razie potrzeby, organizacja potrzebuje solidnej strategii, która okresowo przechowuje i archiwizuje dzienniki, tak aby osoba atakująca lub anomalia systemowa nie wymazała ich z dysku twardego systemu. Chociaż istnieje wiele sposobów, aby to osiągnąć, często stosowana niedroga metoda polega na ustanowieniu serwera dziennika. Na przykład organizacja może zidentyfikować zużyty komputer stacjonarny, wyposażyć go w nowy, szybki napęd optyczny o dużej pojemności tylko do odczytu (ROM) i zwiększyć pojemność pamięci (w razie potrzeby). Dzięki częstemu kierowaniu dzienników do napędu optycznego i nagrywaniu ich w ciągu dnia (może kilka razy w ciągu godziny) oraz wymianie dysku optycznego co najmniej raz dziennie, organizacja stworzy archiwum kryminalistyczne, które będzie można łatwo powielić w celach badawczych i organach ścigania. lub legalny użytek. Często ilość dzienników dziennych nie zapełni płyty DVD lub CD. Jednak regularna rutyna codziennego zmieniania mediów pomaga zapewnić, że media nie osiągną swoich możliwości w nieodpowiednim czasie – w rzeczywistości, jeśli robak, taki jak Blaster lub Nimda, zainfekuje organizację, logi prawdopodobnie szybko się pęcznieją. Ponadto, jeśli atakujący w systemie przerwie rejestrowanie, organizacja powinna mieć mniejsze trudności z określeniem daty, godziny (lub przedziału czasowego) i zakresu włamania, ponieważ pamięci ROM nie można nadpisać, w przeciwieństwie do nośników do odczytu i zapisu (RW). . Czasami można zidentyfikować nieautoryzowane zmiany w kodzie i danych, nawet jeśli sprawca zatrzyma rejestrowanie i usunie lub zmodyfikuje pliki dziennika. Jedną z metod jest tworzenie sum kontrolnych dla produkcji lub innych oficjalnych wersji oprogramowania oraz ochrona sum kontrolnych przed nieautoryzowanym dostępem i modyfikacją za pomocą szyfrowania i podpisów cyfrowych. Podobnie nieautoryzowane modyfikacje danych mogą być czasami utrudnione przez tworzenie sum kontrolnych dla rekordów i łączenie ich ze znacznikami czasu i danych oraz z sumami kontrolnymi dla autoryzowanych programów. W takich warunkach nieautoryzowany personel i intruzi mają trudności z utworzeniem prawidłowych sum kontrolnych dla zmodyfikowanych rekordów. Inne produkty, takie jak systemy wykrywania włamań (IDS) lub systemy zapobiegania włamaniom (IPS), mogą być przydatne w strategii ochrony i zarządzania ryzykiem organizacji.

WNIOSEK

Przedstawiono kompleksowy przegląd procesów tworzenia oprogramowania i zapewniania jakości, które należy stosować podczas opracowywania, wdrażania i modyfikowania oprogramowania. Tworzenie oprogramowania obejmuje coś więcej niż tylko wybór i wykorzystanie podejścia, takiego jak metodologia tradycyjna, kaskadowa lub RAD. Oznacza to pracę zespołową w celu opracowania, przeglądu, udoskonalenia i wdrożenia opłacalnego działającego produktu. Wiele dobrych technik i produktów można zastosować zarówno do części SDLC, jak i zapewniania jakości oprogramowania; niektóre z kluczowych elementów to dobra dokumentacja, zapewniająca wystarczającą ilość czasu na testowanie w procesach rozwoju i utrzymania, budowanie dobrych testów, ustalanie danych testowych, automatyzacja testowania i śledzenie żądań zmian.

Cyberbezpieczeństwo : Reakcja na incydent w chmurze

Kiedy mówimy o cloud computingu, mówimy o współodpowiedzialności (4) pomiędzy dostawcą chmury a firmą zlecającą usługę. Poziom odpowiedzialności będzie się różnić w zależności od modelu usługi, jak pokazano na poniższym schemacie:

W przypadku oprogramowania jako usługi (SaaS) większość odpowiedzialności spoczywa na dostawcy chmury; w rzeczywistości obowiązkiem klienta jest zapewnienie ochrony swojej infrastruktury w pomieszczeniach (w tym punktu końcowego, który uzyskuje dostęp do zasobu w chmurze). W przypadku infrastruktury jako usługi (IaaS) większość odpowiedzialności spoczywa na kliencie, w tym zarządzanie lukami i poprawkami. Zrozumienie odpowiedzialności jest ważne dla zrozumienia granic gromadzenia danych na potrzeby reagowania na incydenty. W środowisku IaaS masz pełną kontrolę nad maszyną wirtualną i pełny dostęp do wszystkich dzienników dostarczanych przez system operacyjny. Jedyne brakujące informacje w tym modelu to podstawowa infrastruktura sieciowa i logi hiperwizora. Każdy dostawca usług w chmurze (5) będzie miał własną politykę dotyczącą gromadzenia danych do celów reagowania na incydenty, dlatego przed zażądaniem jakichkolwiek danych należy zapoznać się z polityką dostawcy usług w chmurze. W przypadku modelu SaaS zdecydowana większość informacji istotnych dla reakcji na incydent jest w posiadaniu dostawcy chmury. W przypadku wykrycia podejrzanych działań w usłudze SaaS należy skontaktować się bezpośrednio z dostawcą chmury lub otworzyć incydent za pośrednictwem portalu (6). Upewnij się, że przejrzysz swoją umowę SLA, aby lepiej zrozumieć zasady zaangażowania w scenariusz reakcji na incydent.

Uszkodzenie danych

Uszkodzenie danych może wystąpić z powodu złego programowania, nieprawidłowego wprowadzania danych, nieodpowiedniego blokowania podczas równoczesnego dostępu do danych i modyfikacji, nielegalnego dostępu jednego procesu do innego stosu danych procesu oraz awarii sprzętu. Uszkodzenie danych może wystąpić nawet wtedy, gdy program jest automatycznie testowany lub uruchamiany bez interwencji człowieka. W każdym razie, szukając źródeł błędów i innych problemów, ważne jest, aby po każdej rundzie testów dokładnie przejrzeć dane, aby zidentyfikować odchylenia od prawidłowego stanu końcowego. Przegląd powinien być odpowiednio udokumentowany i przekazany kierownictwu; następnie wesprze wysiłki w zakresie zgodności z przepisami.

Cyberbezpieczeństwo : Zdobyta wiedza

Po przeczytaniu tego scenariusza możesz zobaczyć przykłady wielu obszarów, które zostały omówione tutaj i które spotkają się podczas incydentu. Ale incydent nie kończy się, gdy problem zostanie rozwiązany. W rzeczywistości jest to dopiero początek zupełnie innego poziomu pracy, którą należy wykonać dla każdego pojedynczego incydentu – dokumentu wyciągniętego z lekcji. Jedna z najcenniejszych informacji, jakie masz w działaniach po incydencie to wyciągnięte wnioski. Pomoże Ci to w dalszym doskonaleniu procesu poprzez identyfikację luk w procesie i obszarów doskonalenia. Kiedy incydent zostanie całkowicie zamknięty, zostanie udokumentowany, a dokumentacja ta musi być bardzo szczegółowa, z pełnym harmonogramem incydentu, krokami, które zostały podjęte w celu rozwiązania problemu, co wydarzyło się na każdym etapie i jak problem został ostatecznie rozwiązany rozwiązane szczegółowo opisane. Ta dokumentacja posłuży jako podstawa do odpowiedzi na następujące pytania:

* Kto zidentyfikował problem z bezpieczeństwem? Użytkownik czy system wykrywania?

* Czy incydent został otwarty z odpowiednim priorytetem?

* Czy zespół ds. bezpieczeństwa przeprowadził prawidłowo wstępną ocenę?

* Czy jest coś, co można by teraz poprawić?

* Czy analiza danych została wykonana poprawnie?

* Czy zabezpieczenie zostało wykonane prawidłowo?

* Czy jest coś, co można by teraz poprawić?

* Ile czasu zajęło rozwiązanie tego incydentu?

Odpowiedzi na te pytania pomogą udoskonalić proces reagowania na incydenty, a także wzbogacą bazę danych incydentów. W systemie zarządzania incydentami wszystkie incydenty powinny być w pełni udokumentowane i możliwe do przeszukiwania. Celem jest stworzenie bazy wiedzy, którą można wykorzystać do przyszłych incydentów. Często incydent można rozwiązać za pomocą tych samych kroków, które zastosowano w poprzednim zdarzeniu. Kolejnym ważnym punktem do omówienia jest przechowywanie dowodów. Wszystkie artefakty, które zostały przechwycone podczas incydentu, należy przechowywać zgodnie z polityką przechowywania firmy, chyba że istnieją konkretne wytyczne dotyczące przechowywania dowodów. Należy pamiętać, że jeśli napastnik musi zostać oskarżony, dowody muszą pozostać nienaruszone, dopóki działania prawne nie zostaną całkowicie uregulowane.

Niewystarczająca lub niespełniająca norm jakość programowania

Programista może stworzyć lub złamać program i projekt. Programiści odgrywają zasadniczą rolę w tworzeniu oprogramowania. Dlatego ważne jest, aby wszyscy programiści biorący udział w projekcie byli zdolni i niezawodni. Programiści projektowi powinni zostać dokładnie sprawdzeni przed umieszczeniem ich w projekcie rozwoju oprogramowania, aby upewnić się, że ich umiejętności spełniają wymagania projektu. Czasami luki w umiejętnościach programistów można wypełnić odpowiednim szkoleniem i coachingiem. Jeśli jednak problemy wydają się spójne, kierownictwo może chcieć sprawdzić doświadczenie programisty, aby sprawdzić, czy nie fałszował on informacji podczas ubiegania się o pracę. Naprawdę niekompetentni programiści muszą zostać usunięci z projektu. Dodatkowo, jeśli kierownictwo podejrzewa, że ​​jakość programowania jest niewystarczająca, powinno rozważyć zlecenie niezależnego programisty przeglądu kodu, wykonującego szczególnie rygorystyczne testy zapewniania jakości (QA).