Problem z tą sytuacją (tak jak ją opisujesz) polega na tym, że przyjmuje się wiele założeń z wieloma opiniami. Masz swoje opinie i chcesz, aby się nimi podzieliły, ale oni mają swoje własne opinie.

Jeśli chcesz, aby wszyscy się na coś zgodzili, musisz znaleźć wspólną płaszczyznę. Musisz zakwestionować i potwierdzić każde założenie oraz znaleźć twarde dane na poparcie swojej lub ich opinii. Gdy już będziecie mieli wspólną płaszczyznę, będziecie mogli razem iść do przodu.

1. Masz białą listę: świetnie, co to znaczy? Czy są sposoby na obejście tego? Czy aplikacja umieszczona na białej liście może zostać uszkodzona?
2. Co robi zapora? Jak to jest skonfigurowane? Firewalle oznaczają zablokowane porty, ale także dozwolone porty. Czy te dozwolone porty mogą być nadużywane?
3. Nikt nie ma dostępu? Kto ma dostęp do urządzenia? Czy ufasz insiderowi lub ignorancji użytkownika, aby zapewnić bezpieczeństwo?
4. Co się stanie, jeśli ktoś uzyska lokalny dostęp do urządzenia? Jakie jest prawdopodobieństwo?

Twoim zadaniem jako specjalisty ds. Bezpieczeństwa informacji nie jest bicie ludzi „sprawdzonymi metodami”, ale przeprowadzanie analiz ryzyka i projektowanie rozwiązań ograniczających ryzyko poniżej progu ryzyka w opłacalny sposób. Musisz uzasadnić nie stosowanie najlepszych praktyk, ale jeśli uzasadnienie jest prawidłowe, to jest prawidłowe.

Jeśli ktoś mówi mi, że jego maszyna nie daje się zhakować i powinienem mu uwierzyć, od razu dochodzę do wniosku, że

• Maszyna jest strzeżona w Fort Knox / więzieniu o zaostrzonym rygorze z 24 / 7 strażników i kamer bezpieczeństwa,

a także jedno z poniższych:

• Maszyna nie wymienia żadnej informacji (bez USB, Ethernet, Firewire, szeregowe, równoległe itp. dowolnego rodzaju)

• Maszyna jest trwale wyłączona.

Ponieważ potrzebujesz wielowarstwowej strategii bezpieczeństwa z dogłębną obroną. Masz zaporę ogniową, ale co zrobić, jeśli w zaporze jest luka w zabezpieczeniach? Co się stanie, jeśli jakiś exploit aplikacji zapewni dostęp do systemu operacyjnego na poziomie użytkownika, a następnie niezałatana luka w systemie operacyjnym umożliwia eskalację tego problemu do uprawnień administratora? Aby zapewnić odpowiednie bezpieczeństwo, musisz załatać wszystkie znane luki, a nie tylko te, które Twoim zdaniem mogą zostać wykorzystane w systemie, ponieważ połączenie nieznanej luki i znanej luki, której Twoim zdaniem nie może być exploited może pozwolić na kompromis tam, gdzie samo w sobie by nie pozwolił, i nie można załatać nieznanych luk w zabezpieczeniach.

Powód jest prosty - zabezpieczenia nakładane są warstwami. Na przykład, aby połączyć się z ważną bazą danych, należy najpierw dostać się do sieci bazy danych (przejść przez firewall), dodać własny adres IP do listy klientów, którzy mogą się połączyć, a następnie zainicjować połączenie za pomocą nazwy użytkownika i hasła. Każda z warstw sprawia, że ​​pozostałe dwie są zbędne. Problem polega na tym, że „co jeśli”. Pomyślmy o domyślnym loginie scott / tiger starej Oracle lub pracownik nieumyślnie przekazuje port do publicznego Internetu. Zapora może blokować tylko TCP, podczas gdy serwer nasłuchuje również na UDP lub IPv6 jest źle skonfigurowany, a zabezpieczenia dotyczą tylko IP4. Z tego powodu dobre zabezpieczenia są warstwowe, próby są monitorowane, a eksperci ds. Bezpieczeństwa uczą się na podstawie prób (miejmy nadzieję, że nie powiodły się) ataków lub sprawdzają aktywność na honeypotach. Ponadto exploity typu zero day (te, które mają zastosowanie nawet do najnowszej łatki) mają mniejsze szanse powodzenia w środowisku warstwowym, ponieważ atakujący będzie potrzebował exploita dla każdej warstwy.

Żadne urządzenie nie może zostać zhakowane, po prostu nie został wcześniej zhakowany. Albo twoje urządzenie ma małe zainteresowania i / lub wypłata jest bardzo niska. Nadal mogą istnieć exploity dnia zerowego.

Ponadto niektórych urządzeń z Androidem po prostu nie można zaktualizować poza określoną wersję. Wiedza o tym, że przeciwnik ma takie urządzenie, jest otwartym zaproszeniem do włamania, ponieważ nazwa / marka urządzenia zawiera dokładny przepis na to, jak je zhakować.

Utrzymanie urządzenia bez aktywnego wsparcia jest niebezpieczne również z powodu funkcjonalności z perspektywy.

Bezpieczeństwo nie jest konieczne, aby chronić przed osobami postronnymi (zapora), ale także przed osobami z zewnątrz. Nie znam kontekstu, w jakim działa twoje urządzenie, ale biorąc pod uwagę to, co piszesz, może być podatne na atak kogoś, kto już znajduje się w zaporze.

Nie ma systemów, których nie można zhakować. Dla tych, którzy wspominają o przepuszczaniu powietrza, istnieje wiele przykładów rzeczywistych hacków lub potencjalnych włamań do systemów z przerwami powietrznymi. Stuxnet jest prawdopodobnie najbardziej znanym (i najbardziej ekstremalnym) przykładem. Niektóre inne obejmują phreaking van Eck, analizę akustyczną lub inne ataki typu side channel.

Istnieją sposoby ograniczania luk w zabezpieczeniach, które nie wymagają łatania. Na przykład, jeśli system jest podatny na KRACK, czy można po prostu wyłączyć WiFi? Jeśli Wi-Fi jest trwale wyłączone, nie powinno być potrzeby aktualizowania go. Podobnie, jeśli w systemie są określone aplikacje, które stanowią lukę w zabezpieczeniach (takie jak Java, .NET, Flash, przeglądarki itp.), Możesz po prostu odinstalować te aplikacje. Nie ma potrzeby aktualizowania oprogramowania Java, jeśli nie jest jeszcze zainstalowana.

W przypadku aktualizacji systemu operacyjnego jest to wprawdzie trudniejsze. Musisz zdawać sobie sprawę z potencjalnych luk w zabezpieczeniach, a następnie musisz je złagodzić. Zaletą korzystania z obsługiwanego systemu operacyjnego jest to, że ktoś inny (prawdopodobnie) już wykonuje za Ciebie pierwszą część i połowę drugiej części.

W pełni zaktualizowany / zaktualizowany system nie jest systemem bezpiecznym ani nie do zhakowania. Ale zazwyczaj minimalizuje ryzyko ZNANYCH luk w zabezpieczeniach. Aby powtórzyć Schroeder, analiza ryzyka jest ważniejsza niż „ulepszanie / blokowanie” lub ślepa „aktualizacja” z nadzieją, że dzięki temu będziesz bezpieczniejszy.

Żaden system nie jest naprawdę „nie do zhakowania”. Jednak gdy już zdecydujemy, że system jest wystarczająco „nie do zhakowania”, nie musimy utrzymywać kanału dla poprawek bezpieczeństwa.

Na konkretny przykład, nasz system „nie do zhakowania” kontroluje kamerę bezpieczeństwa. Zadaniem aparatu jest patrzenie w ustalone miejsce. Każde ustawienie jest stałe lub system jest wystarczająco inteligentny, aby dostosować się sam. System przesyła strumieniowo dane wideo i nie potrzebuje żadnych danych wejściowych od użytkownika.

Moglibyśmy uruchomić ssh, abyśmy mogli okresowo logować się i stosować poprawki bezpieczeństwa, ale to faktycznie otwiera (bardzo mały) dziura w zabezpieczeniach. Atakujący może użyć ssh do zhakowania kamery. (Powodzenia w hakowaniu ssh).

Więc to jest kompromis. Jeśli naprawdę uważasz, że nigdy nie będziesz musiał instalować łatki bezpieczeństwa, możesz zdecydować, że pozostawienie tego kanału otwartego nie jest tego warte.

Pomysł zrodził się z prezentacji, w której uczestniczyłem, gdzie ktoś opisał systemy, w których budowali dla rządu. Składnikami systemu były krótkotrwałe maszyny wirtualne (zwykle krótsze niż jeden dzień). Każda maszyna wirtualna była niezmienna i jednorazowa. Plan był taki, że gdyby potrzebowali zastosować łatkę bezpieczeństwa, po prostu pozbyliby się maszyn w uporządkowany sposób i stworzyli nowe. Maszyny wirtualne nie miały ssh.

Rządowy audytor bezpieczeństwa wydmuchał uszczelkę i zmusił ich do zainstalowania ssh, aby mogli zastosować poprawki zabezpieczeń. Serwer ssh nie zapewniał żadnej wartości bezpieczeństwa i był w rzeczywistości dziurą.

Jednak jeśli o tym myślę, ten (i mój aparat) przykład to tylko aktualizacje zabezpieczeń przez nietradycyjny kanał.

A co z

1. kamerą rozmieszczoną na Marsie ... każdy wie o kamerze i każdy może oglądać dane z kamery
2. kamerę, która znajduje się potajemnie za liniami wroga (gdyby wróg wiedział o kamerze, z łatwością mógłby ją zabrać ... czy chcemy utrzymywać kanał aktualizacji zabezpieczeń).

Fakt, że nie mogą wymyślić (w tej chwili) sposobu na zhakowanie go, nie oznacza, że ​​jest on „nie do zhakowania”. Dlatego z zasady stosujemy wszystkie poprawki zabezpieczeń, nawet jeśli są one na komponencie, który nie powinien być dostępny (np. Po co załatać lukę w zabezpieczeniach eskalacji uprawnień, skoro atakujący nie miałby nawet dostępu użytkownika?).

Teraz mogą mieć rację, a nie łatanie tego może być właściwą decyzją w twoim przypadku. Ale jest kilka osób, dla których bym to zaakceptował. A ci inżynierowie prawdopodobnie nie mają szczególnej wiedzy na temat przeprowadzania audytów bezpieczeństwa.

Jako argument za ich przekonaniem, poprosiłbym ich o udostępnienie jednego z tych urządzeń każdemu zainteresowanemu soczysta nagroda (np. postawili zakład?).

Jeśli czują się nieswojo, robiąc to, cóż, tak naprawdę nie uważają, że jest to niemożliwe do zhakowania. A jeśli uważają, że takie postępowanie ujawniłoby ważne informacje, oznacza to, że polegają na bezpieczeństwie przez zaciemnienie. Prawdziwy system, którego nie da się zhakować, byłby nadal możliwy do zhakowania, gdyby atakujący wiedział wszystko o jego działaniu.

PS: Nawet jeśli nie obstawią swoich domów, naprawdę skorzystasz na wdrożeniu programu wykrywania błędów.

Inżynierowie, którzy zaprojektowali oryginalny produkt, uważają, że maszyny nie da się zhakować

Inżynierowie, którzy zaprojektowali Titanica, uznali, że jest niezatapialny.

Problem w IT polega na tym, że ludzie nie widzą potrzeby aktualizowania systemu, po co zmieniać działający system? Te firmy trafiają na pierwsze strony gazet: „4 fabryki zostały zamknięte z powodu wybuchu epidemii x” lub „Firma x została naruszona, dane osobowe y milionów klientów zostały ujawnione”.

Wyobraź sobie, że chmura IBM niedawno przeniosła wszystkie klienci na siłę do TLS 1.1 (TAK, już przestarzała wersja) i niektórzy klienci narzekali ... TEN KLIENCI POWINNI PRZYGOTOWAĆ SIĘ DO TLS 1.3, nie wiem, co robią, i nie obchodzi mnie, jakie mają wymówki, powinni korzystać z TLS 1.2 WSZĘDZIE! IBM z powrotem sprzedał, NIEDOPUSZCZALNY!

Teraz możesz mi powiedzieć, że czarny jednorożec w stajni uniemożliwia Ci przeniesienie wszystkiego do TLS 1.2, cokolwiek, pozbądź się go i nie współpracuj z firmą sprzedającą czarny jednorożec ... My jako branża tego nie robimy, a naruszenia będą pojawiać się na pierwszych stronach gazet, a naruszenia będą pojawiać się na pierwszych stronach gazet, dopóki nie wyciągniemy wniosków.

czuć, że maszyna nie daje się zhakować

Uczucia nie mają znaczenia. Fakty tak.

Wróć do oceny ryzyka i / lub modelu zagrożenia. Sprawdź, czy łatanie lub aktualizowanie oprogramowania było częścią planu leczenia ryzyka. Sprawdź, czy przestarzałe oprogramowanie było częścią analizy ryzyka lub modelu zagrożeń.

Wróć do inżynierów, podając te fakty i omów z nimi, jak zmienia się ryzyko lub które zagrożenia są teraz nieleczone. w oparciu o fakt, że oprogramowanie nie jest już nieaktualne. należy również wziąć pod uwagę, że to szczególne ryzyko będzie rosło z czasem , wraz ze wzrostem szansy na wykrycie defektu, który można wykorzystać. Więc patrz w przyszłość, aż do rozsądnego końca okresu eksploatacji produktu.

Pamiętaj, że ich działania łagodzące mogą sprawić, że ryzyko będzie akceptowalne. Należy to jednak przedyskutować i zaktualizować plan ryzyka. Może się też zdarzyć, że dzięki temu ryzyko będzie dziś akceptowalne, ale za kilka lat już nie. Co wtedy Zamiast szukać argumentów przeciwko inżynierom, wejdź z nimi na tę samą stronę. Przynajmniej zdajesz sobie sprawę, że mogą być potrzebne działania łagodzące.

„Systemu nie można zhakować, więc po co łatać luki w zabezpieczeniach?” W swoim pytaniu próbujesz argumentować przeciwko błędnemu przekonaniu i argumentowi, którego nie da się udowodnić („Skąd wiesz , że jest„ nie do zhakowania ”? A może po prostu myślisz, że skoro nie możesz tego zhakować, nikt inny nie może? ”). Myślę jednak, że ostatecznie sprowadzi się to do dyskusji na temat akceptowalności ryzyka i tego, kto jest skłonny je zaakceptować. Spróbuj im to wyjaśnić w ten sposób.

„Mamy białą listę aplikacji, więc po co nam łatanie luk w zabezpieczeniach?”

Biała lista aplikacji jest tylko dobre jak sama biała lista, narzędzia do blokowania aplikacji spoza tej białej listy i zakładają, że w samym narzędziu do białej listy aplikacji nie ma błędów ani luk w zabezpieczeniach. Chroni również tylko przed nieznanymi / niezaufanymi aplikacjami. A jeśli atakujący zdecyduje się „żyć z ziemi” i użyć własnych narzędzi systemu przeciwko sobie? Co się stanie, jeśli jedna z aplikacji umieszczonych na białej liście jako część systemu operacyjnego ma lukę w zabezpieczeniach

„Mamy zaporę ogniową, więc po co nam łatanie luk w zabezpieczeniach?” To jest: w rzeczywistości ten sam argument, co poprzedni. Czy jesteś pewien, absolutnie, pozytywnie, w 100%, poza cieniem wątpliwości, że nie ma żadnych luk w stosie sieciowym i / lub samej zaporze sieciowej, ani żadnej z aplikacji lub usług, które mogą nasłuchiwać lub być dostępne za pośrednictwem tego stosu sieciowego?

Jeśli ich odpowiedzi na powyższe pytania są takie, że są w 100% pozytywni co do swoich wyborów i decyzji, napisałbym dokument szczegółowo opisujący akceptację tego ryzyka i podpisany przez ich zespół kierowniczy aż do CIO. Ostatecznie to ich (poziom CxO) jest na haku za problem, jeśli i kiedy system zostanie naruszony i to oni mogą zostać wezwani przed Kongresem (lub jakimkolwiek rządowym organem nadzorczym, któremu podlegają), a także kierownictwo w Equifax były. Kiedy zostanie wyjaśnione kierownictwu, że nie robią wszystkiego, co w ich mocy, aby system był aktualizowany i łatany (zgodnie z wymogami wielu różnych grup / przepisów dotyczących poświadczania i nadzoru) i że oni (CxO) mogą zostać pociągnięci do odpowiedzialności, postawy często się zmieni.

Wydaje mi się to proste. Wracając do pytania, jak dojść do argumentu przeciwko niepoprawowaniu systemu uważanego za nie do zhakowania. Jaki jest najgorszy scenariusz, który może się zdarzyć, jeśli system zostanie naruszony? Załóżmy, że wszystkie istniejące zabezpieczenia zawiodły lub zostały naruszone. Nie lekceważ tego ćwiczenia, pomijając konsekwencje, ponieważ nie uważasz, że może lub zostanie naruszone.

Teraz umieść ten najgorszy scenariusz w kontekście kosztów biznesowych w postaci utraconych przychodów, kar prawnych / regulacyjnych lub szkody dla wizerunku firmy w branży.

Jeśli ten wpływ jest poważny, spójrz swoim inżynierom w oczy i powiedz „Czy jesteś gotów postawić swoją pracę - i być może całą swoją karierę - zagrozić, że to się nigdy nie wydarzy? po wyjaśnieniu, jak to się stało, świadoma decyzja o dalszym korzystaniu z systemu operacyjnego EOL i uznanie, że łatanie jest niepotrzebne, znajdzie się blisko, jeśli nie na szczycie listy. ”

Z drugiej strony, jeśli wpływ biznesowy nie ma takiego wpływu, dalsze korzystanie z systemu operacyjnego EOL może mieć sens. Ale jak najlepiej to zrobić w sposób dobrze zarządzany ryzykiem, to już inny temat.

To może wcale nie być decyzja techniczna. Korzystanie z dowolnego komponentu pochodzącego z zewnątrz ogólnie oznacza, że ​​musisz używać tego komponentu ściśle zgodnie z wytycznymi jego producenta, w przeciwnym razie ryzykujesz, że utkniesz ze wszystkimi konsekwencjami i odpowiedzialnością wynikającą z wszelkich awarii, w które może być powiązany.

Więc jeśli urządzenie zachowuje się nieprawidłowo i ktoś jest ranny (lub poniesie inną odpowiedzialność), wówczas producent oryginalnego systemu operacyjnego powie „nieobsługiwane oprogramowanie - to nie nasz problem”. Ubezpieczyciel Twojej firmy powie: „używanie przestarzałego oprogramowania, które nie jest objęte pomocą techniczną - to zaniedbanie, a więc nie nasz problem”.

Dlatego z osobistego punktu widzenia upewnij się, że osoby podejmujące decyzję pozytywną o kontynuowaniu używają przestarzałych, nieobsługiwanych komponentów:

• pokazano, że to robią (i masz to na piśmie)
• potwierdzili, że aktualizacja jest niepotrzebna ( i zrobili to na piśmie)

Jest duża przepaść między ludźmi, którzy mówią „nie musimy robić tego uaktualnienia” a „Osobiście przyjmuję odpowiedzialność za to, że nie robię tego uaktualnienia” .

W praktyce często zdarzają się aktualizacje komponentów, które są wymagane przez nich po przejściu na EOL, nawet jeśli nie ma takich technicznych potrzeb. To niezbędna część projektowania złożonego produktu.

Jeśli Twoje urządzenie ma połączenie Wi-Fi, może zostać zaatakowane przez sieć. Czy ten atak się powiedzie? Jest to kwestia korzyści z ataku na urządzenie w porównaniu z wymaganym poziomem wysiłku. Oparcie go na przestarzałym i nieobsługiwanym systemie operacyjnym zdecydowanie upraszcza metodę ataku.

Biała lista aplikacji nie jest ochroną, a jedynie niewielką przeszkodą na wyłączność. Myślisz, że haker nie może stworzyć aplikacji, która udaje aplikację z białej listy aplikacji? Oczywiście, że mogą ... coś, na co mogą spojrzeć, jeśli ich pierwsza próba się nie powiedzie.

Equifax miał zainstalowaną całkiem sporą zaporę ogniową. Nie powstrzymało to hakerów przed wykorzystaniem luki w Struts, której menedżerowie IT Equifax nie zdołali załatać, przez port, który został otwarty z konieczności. Zapora ogniowa po prostu zatrzymuje niektóre starsze, oczywiste ataki.

Przypomnij sobie hack Target - dyrektor generalny i dyrektor ds. informatyki stracili pracę przez to, a został on popełniony przez osobę wewnętrzną, wspomaganą przez użycie przez Target starszej wersji systemu Windows, która nie jest już aktualizowana, a także starszej , niezabezpieczone metody łączności na urządzeniach w punktach sprzedaży. Bez wątpienia CIO doszedł do wniosku, że aktualizacja wersji Win na ich urządzeniach POS była zbyt droga, co okazało się bardzo błędne.

Myślisz, że wbudowane oprogramowanie układowe jest odporne na włamania? Weź pod uwagę włamanie do drukarki HP. Firma HP wpadła na sprytny pomysł aktualizacji oprogramowania sprzętowego drukarki poprzez zadanie drukowania - łatwe do zainicjowania. Aż ... ktoś wymyślił wersję oprogramowania układowego, która zamieniła drukarkę w przekaźnik spamu i dostarczyła ją za pośrednictwem zadania drukowania zawierającego złośliwe oprogramowanie.

Jak aktualizuje się oprogramowanie sprzętowe? Przez Wi-Fi? Tak, haker może to powtórzyć ... jeśli ma wystarczająco dobry powód.

Urządzenie sieciowe może zostać zhakowane, aby stać się częścią botnetu ... częstym sposobem przeprowadzania ataku DOS. Haker może znaleźć lukę i wiedząc, że zaszkodziłoby to reputacji firmy, przeprowadzić atak w tym samym czasie, w którym następuje skrócenie akcji Twojej firmy. Tak się stało ... Kradzież informacji umożliwiających identyfikację użytkownika i CC to nie jedyny sposób na czerpanie korzyści z włamania.

Teraz zadaj sobie pytanie - jakie jest ryzyko dla ciebie osobiście? Jeśli Twój system miałby zostać zhakowany, czy możesz wykazać kierownictwu swojej firmy, że dołożyłeś należytej staranności w identyfikowaniu i ograniczaniu potencjalnych zagrożeń, zwłaszcza, że ​​opierasz system na systemie operacyjnym, który nie jest już aktualizowany? Wskazówka: biorąc słowo inżynierów, którzy twierdzą, że system jest „nie do zhakowania”, prawdopodobnie nie kwalifikuje się jako należyta staranność.

Jeśli o to chodzi, jeśli twoi inżynierowie twierdzą, że nie da się tego zhakować, prawdopodobnie nawet nie szukają potencjalnych luk, nie mówiąc już o ich łagodzeniu.

Każdy, kto twierdzi, że systemu nie da się zhakować, po prostu nie jest realistą. Nie w dzisiejszych czasach.

W zależności od dostępnych zasobów, sposobem "głupiego dowodu" (z całym szacunkiem dla twoich kolegów) byłoby udowodnienie im, że system daje się zhakować. Zatrudnij kogoś, kto może i pozwól mu zademonstrować słabości systemu. Domyślam się, że z WLAN nie powinno to być strasznie trudne. WLAN i firewall? To jest contradictio in adjecto .

Po namyśle: Być może można uzgodnić zapłatę za sukces (mój słownik nazywa to „opłatą awaryjną”); w ten sposób usługa (hakerska) zawsze byłaby warta swojej ceny.

Każdego dnia mamy nagłówki, że jakiś system został zhakowany. Nie dlatego, że nie są aktualne ani chronione karabinami maszynowymi, ale dlatego, że ktoś inwestuje czas, aby je zhakować.

Co najważniejsze, te, które są dobrze rozegrane, nie są tworzone przez siłę IQ, ale przez prostą inżynierię społeczną. Dlatego mówi się nam, abyśmy aktualizowali system, ponieważ jeśli w jakiś sposób wpadliśmy do tej dziury, podajemy informacje, które im nie pomagają.