Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Podczas ustanawiania dziedziny Architektura zabezpieczeń ten artykuł zawiera wskazówki dotyczące stosowania 10 niezmiennych przepisów dotyczących ryzyka zabezpieczeń jako praktycznych wskazówek podczas ustanawiania i modernizacji dziedziny Architektura zabezpieczeń.
Przegląd niezmiennych przepisów dotyczących zabezpieczeń
Architektura istnieje, aby zidentyfikować trudne wymagania i przełożyć je na wskazówki umożliwiające podejmowanie działań, aby zmniejszyć ryzyko bezpieczeństwa, ograniczyć uszkodzenia i zachować systemy dostępne w czasie. Podstawą tej pracy są niezmienne prawa zabezpieczeń.
Przepisy te opisują niewygodne prawdy o bezpieczeństwie, które ułatwiają planowanie skutecznej kontroli, unikanie typowych nieporozumień, które podważają architekturę zabezpieczeń i tworzą ryzyko organizacyjne.
| Niezmienne prawo | Wpływ architektury |
|---|---|
| 1. Jeśli osoba o złych zamiarach może przekonać Cię do uruchomienia jej programu, to nie jest Twój komputer | Nieautoryzowane wykonywanie kodu powoduje utratę kontroli. Samo zapobieganie jest niewystarczające. |
| 2. Jeśli zły aktor może zmienić system operacyjny, nie jest to komputer | Naruszenie płaszczyzny sterowania stanowi ryzyko systemowe. Dotyczy to tego, czy płaszczyzna sterowania jest lokalnym systemem operacyjnym, systemem zarządzania tożsamościami, narzędziem zabezpieczeń, czy innymi elementami z dostępem na poziomie systemu/głównego. |
| 3. Jeśli osoba niepowołana ma nieograniczony fizyczny dostęp, to nie jest już twój komputer | Należy przyjąć, że ekspozycja fizyczna nie jest traktowana jako wyjątek. |
| 4. Jeśli atakujący może uruchamiać aktywną treść w Twojej witrynie, to nie jest już Twoja witryna | Granice wykonania definiują granice zaufania. |
| 5. Słabe hasła niweczą silne zabezpieczenia | Naruszenia tożsamości niweczą wielowarstwowe zabezpieczenia. |
| 6. Komputer jest tylko tak bezpieczny, jak jego administrator | Dostęp uprzywilejowany jest niezwykle ważnym priorytetem zabezpieczeń. |
| 7. Zaszyfrowane dane są bezpieczne tylko jako klucz odszyfrowywania | Kryptografia bez nadzoru jest krucha. |
| 8. Nieaktualny skaner ochrony przed złośliwym kodem jest nieznacznie lepszy niż żaden | Statyczne systemy obronne zanikają. |
| 9. Bezwzględna anonimowość nie jest osiągalna | Widoczność jest nieunikniona. |
| 10. Technologia nie jest panaceum | Należy zakładać możliwość błędów ludzkich i procesowych. |
Stosowanie dziesięciu praw ryzyka cyberbezpieczeństwa
Nawet po zrozumieniu, w jaki sposób kontrola zabezpieczeń jest potencjalnie utracona i wpływ na architekturę zabezpieczeń, nie wystarczy informacji, aby zaprojektować system. Architekci zabezpieczeń muszą również zrozumieć:
- Pod kątem czego optymalizujemy? - Gdzie koncentrujemy wysiłek? - Jakie kompromisy są dopuszczalne?
Aby ustalić te pytania, możemy zastosować 10 typowych przepisów dotyczących ryzyka cyberbezpieczeństwa. Każdy zestaw przepisów dotyczy różnych aspektów cyberbezpieczeństwa.
| Prawa | Implikacja architektury | Wskazówki dotyczące modernizacji |
|---|---|---|
| 1. Powodzenie zabezpieczeń rujnuje zwrot z inwestycji atakującego | Projektuj architektury, które zwiększają koszty ataku i ograniczają korzyści, zwłaszcza w przypadku zasobów o wysokiej wartości. | - Skoncentruj kontrolę nad tożsamościami, uprzywilejowanym dostępem i poufnymi danymi. - Ogranicz płaskie strefy zaufania; segmentuj systemy, aby naruszenie nie rozprzestrzeniało się na większą skalę. - Określanie priorytetów ochrony, które przerywają typowe łańcuchy atakujących, a nie specjalne przypadki. |
| 2. Kto nie dotrzymuje kroku, zostaje w tyle | Architektury statyczne kończą się niepowodzeniem. Architektura musi zakładać ciągłą ewolucję. | — Architektura bezpieczeństwa nigdy nie jest ukończona. Musi ona być zrównoważona operacyjnie i stale ulepszana. — Projektowanie pod kątem ciągłej aktualizacji (stosowanie poprawek, konfiguracja, zasady). — Preferuj usługi natywne dla chmury i zarządzane, które ewoluują szybciej niż systemy lokalne lub na zamówienie. — Dopilnuj, aby widoczność i inwentaryzacja stanowiły wymogi architektoniczne, a nie coś, o czym myśli się dopiero później. |
| 3. Bezpieczeństwo jest elementem umożliwiającym działalność biznesową (produktywność zawsze wygrywa) | Jeśli architektura powoduje utrudnienia, będzie omijana. | — Dobra architektura zabezpieczeń domyślnie zapewnia produktywność. — Preferuj dostęp oparty na tożsamości zamiast złożonej architektury sieci. — Integrowanie mechanizmów kontroli zabezpieczeń z przepływami pracy użytkowników standardowych i deweloperów. - Spraw, aby bezpieczne rozwiązania były najłatwiejszym wyborem. |
| 4. Atakujący się nie przejmują | Osoby atakujące używają dowolnej dostępnej ścieżki dostępu w środowisku. Architektura musi wyeliminować najtańsze ścieżki, a nie bronić tylko oczywistych. | - Architektura musi odzwierciedlać rzeczywiste działania atakującego, a nie wyidealizowane założenia dotyczące poszczególnych mechanizmów zabezpieczeń. — Zakładaj naruszenie w wyniku phishingu, błędnej konfiguracji lub przestarzałych protokołów. - Wyeliminuj architektoniczne pojedyncze punkty awarii. — Chroń przed całym cyklem ataku (ruch boczny, realizacja celów ataku), a nie tylko przed początkowym dostępem. |
| 5. Bezwzględna priorytetyzacja jest umiejętnością przetrwania | Nie można zabezpieczyć wszystkiego. | - Architektura polega na wyborze tego, czego nie robić. - Zidentyfikuj tam aktywa klejnotów koronnych i zaprojektuj "obronę w głębi". - Zaakceptuj niższe zapewnienie, gdzie wpływ na działalność biznesową jest niższy. — Użyj scenariuszy biznesowych, aby kierować inwestycjami w architekturę. |
| 6. Cyberbezpieczeństwo jest sportem zespołowym | Architektura musi integrować pracę między dyscyplinami i zespołami. | - Architekci projektują koordynację, a nie tylko kontrole. - Dopasowanie architektury do zespołów platformy, deweloperów i operacji. — Deleguj mechanizmy kontroli do platform, które mogą wykonywać je lepiej (dostawcy usług w chmurze, systemy tożsamości). - Unikaj rozwiązań niestandardowych, w których wystarczające są usługi udostępnione. |
| 7. Twoja sieć nie jest tak godna zaufania, jak uważasz, że jest | Zaufanie sieciowe nigdy nie może być podstawową lub jedyną płaszczyzną sterowania. | - Prawo to stanowi podstawę odejścia od projektu skoncentrowanego na obwodzie. — Zmiana decyzji dotyczących zaufania na tożsamość, urządzenie i kontekst aplikacji. - Architektury projektowe, które zakładają, że sieć jest zauważalna i wroga. — Zachowaj skuteczne mechanizmy kontroli, takie jak zapory/zapory aplikacji internetowej (WAFs), ale nie polegaj na nich w celu wykrywania/blokowania wszystkiego. — Używaj modeli dostępu Zero Trust spójnie w różnych środowiskach. |
| 8. Izolowane sieci nie są automatycznie bezpieczne | Izolacja jest skuteczna tylko wtedy, gdy jest rygorystycznie zaprojektowana i utrzymywana. | — Zachowaj izolację sieci, która działa dobrze. Upewnij się, że go utrzymujesz, a osoby atakujące nie mogą łatwo go obejść. — Architektura musi uwzględniać osoby i procesy, a nie tylko topologię. - Traktuj izolację jako system, a nie regułę filtrowania sieci. - Zabezpiecz wszystkie punkty połączeń pośrednich (nośniki, dostęp dostawców, administratorzy). - Zakładaj, że doszło do naruszenia, i stosuj silne mechanizmy kontroli tożsamości oraz zabezpieczenia operacyjne, nawet w architekturze izolowanej od sieci. |
| 9. Szyfrowanie same nie jest rozwiązaniem do ochrony danych | Kryptografia jest tylko tak bezpieczna, jak klucze, które ją chronią. | - Szyfrowanie jest ważne, ale jest nieskuteczne bez bezpiecznej implementacji i operacji. - Zaprojektuj scentralizowane zarządzanie kluczami i nadzór nad dostępem. - Chroń ścieżki deszyfrowania równie rygorystycznie jak zaszyfrowane nośniki danych. - Połącz szyfrowanie z zarządzaniem tożsamością, monitorowaniem i egzekwowaniem zasad. |
| 10. Technologia nie rozwiązuje problemów z ludźmi i procesami | Architektura musi zakładać niedoskonałe ludzi i procesy. | - Zmodernizuj architekturę bezpieczeństwa, aby ograniczyć skalę skutków błędu ludzkiego. Nie dopuść, aby kliknięcie pojedynczego phishingowego e-maila osłabiło poziom bezpieczeństwa. - Projektowanie systemów odpornych na błędy. - Automatyzuj zabezpieczenia tam, gdzie to możliwe. - Unikaj architektur, które zależą od nieskazitelnej operacji ręcznej. |
Tworzenie architektury
Jako architekt zabezpieczeń możesz użyć tych dwóch tabel jako obiektywów uzupełniających. Jeden do weryfikacji kondycji technicznej, a drugi do napędzania priorytetyzacji opartej na ryzyku. W połączeniu tworzą praktyczne ramy decyzyjne dotyczące projektowania i modernizacji architektury.
| Przepisy | Cel | Zastosowanie architektoniczne | Pytania, na które udzielono odpowiedzi |
|---|---|---|---|
| Niezmienne prawa zabezpieczeń | Uchwyć zasady techniczne, które zawsze pozostają prawdziwe. | Upewnij się, że architektury nie naruszają rzeczywistości technicznej. Założenia testowe Zweryfikuj granice zaufania. Unikaj fałszywego zaufania. |
Czy architektura jest zasadniczo dobra? Czy projekt polega na czymś, co można łatwo pominąć? Czy zakładamy, że technologia może nadrobić niezaufanych administratorów, słabych haseł lub metod dostępu fizycznego? Czy mylimy szyfrowanie, izolację lub narzędzia do rzeczywistej kontroli? |
| Przepisy dotyczące ryzyka cyberbezpieczeństwa | Zdecyduj, co ma największe znaczenie. | Określ, gdzie zainwestować nakład pracy nad architekturą. Kształtuj plany modernizacji. Uzasadniaj kompromisy dla liderów biznesowych. |
Gdzie atakujący otrzymują największą wypłatę za najmniejszy wysiłek? Które kontrolki rzeczywiście zmieniają zachowanie osoby atakującej? Jaka praca nie jest już warta wykonania? |
Example
Więc jeśli weźmiemy przykład, który stosuje obie tabele razem.
| Decyzja projektowa | Perspektywa niezmiennych praw | Dziesięć praw obiektywu |
|---|---|---|
| Zmniejsz zależność od sieciowych list ACL na rzecz dostępu opartego na tożsamości | Sieci nie są godne zaufania, liczy się tożsamość. | Podnosi koszt osoby atakującej i jest zgodny z zasadami Zero Trust. |
| Nadaj priorytet MFA dla administratorów, zanim utwardzisz zapory brzegowe. | Słabe hasła niweczą nawet solidne zabezpieczenia. | Najtańszy sposób zerwania typowych łańcuchów ataków. |
| Segmentowanie obciążeń zamiast polegać na "lukach w powietrzu" | Izolacja nie jest automatycznie bezpieczna. | Ogranicza skalę szkód, gdy atakujący uzyskają dostęp. |
| Automatyzacja wdrażania poprawek i wykrywania dryfu konfiguracji | Nieaktualne zabezpieczenia kończą się niepowodzeniem. | Kto nie nadąża, zostaje w tyle |
Korzystanie z obu tabel prowadzi do architektur zabezpieczeń, które:
- Przyjmij kompromis, skoncentruj się na ograniczeniu ryzyka i uszkodzeniu, a nie na obiecującym absolutnym zapobieganiu.
- Skoncentruj się na tożsamości, uprawnieniach i ruchu bocznym, a nie tylko na ochronie obwodowej.
- Przyjmij ciągłe zmiany i ewolucję, a nie diagramy statyczne.
- Równoważenie produktywności biznesowej dzięki zmniejszeniu ryzyka. Dopasowanie mechanizmów kontroli zabezpieczeń do wartości biznesowej.
- Integrowanie osób, procesów i technologii.
- Zmniejsz opłacalność działań atakującego, zamiast dążyć do idealnego bezpieczeństwa.
- Stosuj zasady Zero Trust całościowo.
Następne kroki
Upewnij się, że zapoznasz się z innymi dyscyplinami zabezpieczeń.