Nie upewniasz się, że wszystkie aktualizacje zabezpieczeń zostały zastosowane? Pamiętaj, że jako obrońca musisz wygrać w 100% . Haker musi wygrać tylko raz.

Kroki, które wymieniłeś, są również o wiele łatwiejsze do powiedzenia niż wykonania (z wyjątkiem kwestii hasła ... a mimo to ludzie nadal wybierają okropne hasła!).

2) Co to jest „wiarygodne źródło” dla publicznego serwera internetowego? Cały Internet? Cały Internet bez Chin / Rosji (/ niektórych / innych / krajów)? Zautomatyzowane systemy mogą wykryć wiele typów ataków, ale podobnie jak programy antywirusowe mogą zajść tylko do tej pory.

3) Monitorowanie plików lokalnych jest dobre, ale znowu nie jest to panaceum. Co się stanie, jeśli atakującemu uda się wstrzyknąć kod do serwera WWW, a następnie użyje błędu jądra, aby pobrać kod do jądra ... bez zapisywania pliku na dysku? W tym momencie mogli zapisywać pliki na dysku i używać zestawu głównego, aby większość (teoretycznie wszystkie ) skanów online nie zauważyła żadnych zmian w systemie.

I nawet jeśli uda im się tylko wykorzystać serwer sieciowy, mogą zrobić wszystko, co może zrobić serwer sieciowy (co może i tak być wszystkim zainteresowanym atakującym).

4) Powinieneś zawsze sprawdzaj poprawność danych wejściowych użytkownika. Większość programistów o tym wie (i wielu próbuje to zrobić). Niestety, o wiele łatwiej jest powiedzieć niż zrobić, dlatego nadal widzimy problem za problemem, w którym dane wejściowe użytkownika nie są odpowiednio weryfikowane. Nigdy nie będziesz w stanie zagwarantować, że jakikolwiek prawdziwy program poprawnie sprawdza wszystkie dane wprowadzone przez użytkownika. Przeczytaj kilka pytań PHP + MySQL w witrynie StackOverflow, aby zobaczyć, ile osób uważa, że ​​ mysqli_real_escape_string () zapobiega wszystkim atakom typu SQL injection ( "where ID =". $ Val jest podatne na ataki, nawet jeśli $ val jest wynikiem działania mysqli_real_escape_string !).

Nawet gdybyś mógł (nie możesz) upewnić się, że każdy znany wektor ataku jest chroniony, nie możesz zrobić nic więcej niż dzikie kołysanie się w ciemności przeciwko nieznanemu-nieznanemu (cóż, ciągłe uczenie się pomaga).

Jako przykład, gdzie twoja obrona nic by nie zrobiła, brałem udział w kursie bezpieczeństwa, podczas którego robimy „gry wojenne”. Udało mi się zrootować serwer drużyny przeciwnej, ponieważ udało mi się usunąć jedno z haseł ich użytkowników z innej maszyny (jeden z nich schrzanił i przez pomyłkę wpisał w bash jako polecenie, a oni nigdy nie pomyśleli aby usunąć go z .bash_history ).

Stamtąd sfałszowałem adres IP maszyny, z której zwykle się logowali, i włączyłem SSH, wprowadzając ich nazwę użytkownika i hasło. Miałem ograniczony dostęp do systemu. Następnie uruchomiłem sudo vim , ponownie wprowadziłem to samo hasło i kazałem vimowi odrodzić powłokę bash. Tada! Dostęp do roota z wiarygodnego źródła, bez modyfikowania jakichkolwiek plików lokalnych w nietypowy sposób, bez wykorzystywania słabego hasła (było złe, ale nawet najlepsze hasło na świecie nie pomogłoby), ani polegania na niewalidowanych danych wejściowych użytkownika.

W tym momencie, będąc złośliwym dla mnie, ręcznie zmodyfikowałem wszystkie pliki dziennika związane z moim legalnym loginem i usunąłem ich IDS (założę się, że nie będą wystarczająco spostrzegawczy, aby zauważyć, że wymieniłem wszystkie jego pliki binarne z kopiami / bin / true !). „Prawdziwy” haker byłby prawdopodobnie znacznie lepiej przygotowany, aby zapewnić, że jego aktywność nie zostanie wykryta przez bardziej czujnych administratorów, ale już osiągnąłem swój cel, a mała część mnie chciała, żeby dowiedzieli się, że ktoś go dostał.

Gdybym mógł zmienić prawo Schneiera:

Każdy, od najbardziej bezmyślnego amatora po najlepszego administratora systemów, może stworzyć system bezpieczeństwa, którego sam nie może złamać.

Krótko mówiąc, odpowiednia obrona nie jest łatwym zadaniem, ponieważ ...

Szybkie uderzenie w swoje dane wejściowe ->

Ustaw długie hasło do konta administratora ...

Samo surfowanie po ramieniu pokonuje wszelkie wysiłki na silnych hasłach.
Dodatkowo, jeśli mechanizmy przechowywania haseł są słabe (podatne na Zastrzyki SQL lub niezabezpieczone mechanizmy mieszania lub, co najgorsze, przechowywanie hasła w postaci zwykłego tekstu), pozostajesz podatny na ataki.

Monitoruj każdy przychodzący ruch sieciowy

Będziesz monitorowanie bardzo dużego ruchu. Jaka jest gwarancja, że ​​nie przegapisz ważnych rzeczy? A co z zero-dniami?
A co z zaszyfrowanym ruchem? Co będziesz na tym monitorować?

... i zezwalać tylko na wiarygodne źródła.

A jeśli Twoje wiarygodne źródła otrzymają zhakowany / zhakowany? Wtedy nie są już bardziej wiarygodne , ale ty, administrator sys, nie wiesz tego!

... monitoruj zmiany w plikach lokalnych ... Sprawdzaj wszystkie dane wprowadzone przez użytkownika. ..

Ponownie, ile możesz monitorować i ile dzienników możesz przeanalizować ...

Ponadto zakładając, że jest co najmniej kilka usług działających w maszyny, luki w usłudze mogą stać się przyczyną naruszenia bezpieczeństwa Twojego komputera.

Mam nadzieję, że mógłbym pokazać, jak hackowanie jest wykonalne :)

Potwierdzenie: Zdjęcie pochodzi z www.quotesparade.com

Gdybyś mógł bronić się „właściwie”, hakerzy nigdy by się do tego nie włączyli. Problem polega na tym, co właściwie oznacza w tego rodzaju sytuacjach.

Mógłbyś wyłączyć serwer i zabetonować go pół mili pod ziemią i jest całkiem bezpieczny, prawda? Ale jest bezużyteczny. A jeśli wartość tego, co się na niej znajduje, jest wystarczająco wysoka, atakujący może spróbować ją wykopać. Na tym skrajnym przykładzie widać już, że bezpieczeństwo to równowaga. Musi być odpowiedni - i nadal umożliwiać korzystanie z serwera.

W takim przypadku napotkane problemy obejmują:

• jak upewnić się, że wszystkie pliki wykonywalne są bezpieczne? Znowu nie możesz. Możesz zdecydować, ile wysiłku chcesz poświęcić na ich sprawdzenie i uruchomić różne testy, ale podstawy kodu są wystarczająco duże dla większości aplikacji, w których wkradają się przypadkowe błędy.
• czy proponowana opcja bezpieczeństwa sprawia, że ​​serwer jest bezużyteczny dla jego docelowi odbiorcy? Odłączenie go od sieci zwiększy bezpieczeństwo, ale nie zadowoli użytkowników.
• czy znasz wszystkie możliwe dane wejściowe, których Twoi użytkownicy mogą chcieć użyć? Jeśli tak, genialnie - biała lista. Pamiętaj jednak, aby aktualizować za każdym razem, gdy aplikacja jest aktualizowana lub ma nowe funkcje. I sprawdzaj za każdym razem, gdy pojawi się nowy użytkownik. I sprawdź, czy biała lista działa, aby zatrzymać wszystkie niezatwierdzone dane wejściowe. I tak dalej ...
• ataki mogą nie wymagać zmiany żadnych plików na dysku. Monitorowanie plików nie wychwytuje na przykład ataków skierowanych bezpośrednio na kod w pamięci.
• dodanie technicznych zabezpieczeń nie uwzględnia ataków społecznych ani fizycznych. Jeśli napastnik naprawdę chce uzyskać dostęp do dobrze chronionego serwera, może uznać, że warto cię podsłuchiwać, rejestrować naciśnięcia klawiszy w celu uzyskania haseł itp. Lub może być łatwiej zasugerować użytkownika - być może jest mniej świadomy bezpieczeństwa.
• etc etc

Mówiąc najprościej - możesz zabezpieczyć się do poziomu w zależności od budżetu. Zdecyduj, ile chcesz wydać na podstawie tego, co chcesz chronić. Zaakceptuj, że będzie pewne ryzyko szczątkowe.

A potem zaplanuj, że coś pójdzie nie tak - w pewnym momencie Twoje zabezpieczenia zostaną złamane i będziesz musiał wiedzieć, jak zareagować. W przypadku prostego serwera plików proces ten można po prostu wyczyścić i ponownie zainstalować z kopii zapasowej, ale w przypadku czegoś bardziej złożonego może być konieczne poinformowanie użytkowników, interesariuszy, organów regulacyjnych itp., Przechowywanie dowodów, wykonywanie kopii kryminalistycznych, przebudowa, rekonfiguracja lub w jakiejś formie naprawa incydent ... a następnie wyciągnij z niego doświadczenia edukacyjne, aby ponownie ocenić swój plan bezpieczeństwa.

... a następnie ... Powtórz to wszystko jeszcze raz. Regularnie oceniaj swoje bezpieczeństwo i apetyt na bezpieczeństwo, ponieważ jest to szybko zmieniający się świat!

Załóżmy, że masz serwer WWW, który wymaga jednego polecenia:

GET /helloworld.txt

A to zwraca po prostu „Hello, World!”

To najłatwiejsza rzecz na świecie do kodowania, prawda? Zakładając, że bierzesz dane wejściowe, sprawdź ciąg „GET /helloworld.txt” i postępuj właściwie, a następnie zignoruj ​​cokolwiek innego. Jakie są możliwości włamania? Brak?

OK. Jaki jest twój bufor poleceń? 20 bajtów? Wystarczająco długo, żeby przyjąć to polecenie? A jeśli ktoś wyda polecenie dłuższe o dwa bajty? A jeśli wydadzą polecenie dłuższe o 2000 bajtów? Jak właściwie otrzymujesz polecenie? Co mówi do karty sieciowej? Co dekoduje pakiet? Co jeśli znaki są wysyłane w dwóch pakietach, bez zakończenia NUL między bajtami?

Krótko mówiąc, nawet ten „najprostszy” program sieciowy, który nawet nie wymaga dostępu do hasła, może mieć DUŻO bezpieczeństwa wady.

Po prostu chodzi o złożoność. Za każdym razem, gdy wprowadzana jest zmienna, liczba MOŻLIWYCH wektorów ataku rośnie wykładniczo. Nie wszystkie z nich będą wektorami ataku, ale MOGŁYby nimi być, więc jeśli chcesz być bezpieczny, musisz je wszystkie uwzględnić.

To prawie niemożliwe, bez w pełni skontrolowanego, w pełni przetestowanego jednostkowo, system zaprojektowany na zamówienie, a może nawet sprawdzony matematycznie. O ile wiem, takiego systemu nie ma. OpenBSD może się zbliżyć, ale wątpię, że to wszystko.

Bardzo krótka odpowiedź brzmi: jeśli chodzi o bezpieczeństwo, zawsze zakładaj najgorsze. DUŻO mądrzej jest wiedzieć, że jesteś bezbronny i działać w odpowiednio skromny sposób, ryzykując tak mało, jak to tylko możliwe, niż zakładać, że jesteś bezpieczny tylko dlatego, że nie możesz wymyślić możliwego wektora ataku.

Jeśli zrobisz wszystko i zrobisz to poprawnie, możesz zapobiec wielu różnym atakom. Niestety, hakowanie to coś więcej niż tylko bezpośredni atak na logowanie / dostęp.

Duża część obejmuje omijanie ochrony, więc atakujący nie musi znać hasła. Inną ważną częścią jest inżynieria społeczna. Hasła niczego nie chronią, jeśli są znane atakującym. Ponadto istnieje więcej szkodliwych ataków i celów niż samo uzyskanie dostępu do panelu administratora. Jeśli ktoś nie chce, żebyś prowadził sklep internetowy, bo ma swój własny i chce trzymać swoich klientów (a Ciebie poza biznesem), jak chcesz zapobiec atakowi DDoS, czy po prostu ktoś wyciąga wtyczkę z twojego serwera Pokój? (Sprzątaczka, która właśnie chciała odkurzyć płytę główną?;))

Poza tym monitorowanie nie pomaga w zapobieganiu atakom.

różne typy zabezpieczeń, systemy reagowania na manipulacje, systemy zabezpieczające przed manipulacją i systemy wykrywania manipulacji. Systemy odporne na manipulacje chcą spowolnić ataki (np. Długie hasła). Tamper reaguje na informację, czy ma miejsce atak (np. Alarm, który uruchamia się, gdy IDS wykryje jakieś ciągi iniekcji SQL), a system wykrywania manipulacji pokazuje, jak doszło do rzeczywistego ataku (np. Pliki dziennika)

Hakerzy próbują złamać lub uniknąć tych zabezpieczeń, a Twoim zadaniem jest być o krok do przodu. Oczywiście jest to bardzo trudne, ponieważ ledwo można rozpoznać jakiekolwiek luki w zabezpieczeniach oprogramowania serwera, które mogą pozwolić atakującemu na dostęp do informacji root bez hasła. Zwykle osoby atakujące najpierw znajdują tego rodzaju słabości, a Twoim zadaniem jest zadbać o system i spowolnić ich ataki, aż problem zostanie naprawiony.

Niech hasło do konta administratora będzie długie i wystarczająco skomplikowane (tj. teoretycznie nie da się złamać hasła w rozsądnym czasie).

Złamane przez brutalną siłę? Nie. Pęknięty przez socjotechnikę? Tak. Jeśli wiele osób zna hasło, uzyskanie go za pomocą inżynierii społecznej nie jest zbyt trudne. (ilekroć więcej niż jedna osoba zna hasło, możliwe jest efektywne wykorzystanie personifikacji w celu uzyskania hasła). Jeśli tylko masz dostęp, nadal fizyczny dostęp można osiągnąć za pomocą inżynierii społecznej. Jednak trudniej sobie z tym poradzić i musisz się zastanowić, czy to naprawdę warte wysiłku.

Monitoruj każdy ruch sieciowy przychodzący do plików administracyjnych.

To nie chroni Cię przed DDoS. A jeśli chcesz chronić się przed atakami DDoS, będzie zbyt wiele fałszywych alarmów użytkowników, którzy zostaną niesłusznie zablokowani.

Nawet jeśli Twoje hasło jest długie, botnet może się włamać. Jeśli masz jakieś ograniczenia ile razy nie uda Ci się wprowadzić hasła, mogą zablokować Ciebie .

Ponadto CAPTCHA nie są już tak bezpieczne, istnieje wiele podmiotów, które płacą za ludzie, aby siedzieć cały dzień i rozwiązywać captcha.

Aby rozszerzyć warstwę ochrony z punktu 2 powyżej, monitoruj zmiany w plikach lokalnych (szczególnie te, które mają polecenia wymagające uprawnień sudo.

Nie możesz w pełni monitorować wszystkich zmian plików. Jest po prostu za dużo informacji. Większość programów robi dużo bałaganu z plikami podczas ich uruchamiania. Jak odróżnić aktualizację programu od złośliwego pliku?

Sprawdź poprawność każdego wpisu użytkownika, aby zagwarantować, że wszystkie dane wejściowe użytkownika są bezpieczne.

Upewnij się, że robisz to po stronie serwera.

Wreszcie , exploity dnia zerowego zawsze będą stanowić problem. Jeśli ktoś znajdzie lukę w zabezpieczeniach we frameworku, z którego korzystasz, jesteś zatopiony. Aby temu zapobiec, użyj powszechnie używanych frameworków i miej nadzieję na najlepsze.

Ochrona przed włamaniami jest jak próba ochrony podwodnego bunkra pełnego sodu. Jest wiele miejsc, które Twoim zdaniem wymagają łatania. Możesz je wszystkie załatać. Ale to nie znaczy, że jesteś bezpieczny - wystarczy mały wyciek w miejscu, którego nie sprawdzałeś, czy wszystko się zawaliło.

„Właściwa ochrona” oznacza: „mój kod nie zawiera błędów; żadne z narzędzi, których używam też nie”. Ale oprogramowanie ma błędy; sprzęt zawiera błędy; nikt nie wie, jak zagwarantować brak błędów w nietrywialnym oprogramowaniu lub sprzęcie (ci, którzy twierdzą, że są przeciwni, mają urojenia lub kłamią, lub jedno i drugie). Zobacz to poprzednie pytanie, aby zapoznać się z dyskusją.

Praktyczny sposób przeprowadzania ataków polega na tym, że atakujący odkrywa lub dowiaduje się o błędzie, który może zostać wykorzystany na swoją korzyść, i zanim właściciel systemu dowiaduje się o tym i naprawia.

Z Twojej listy:

• Duże, grube, losowe, niemożliwe do odgadnięcia hasło administratora jest w porządku - o ile maszyna na których administrator wpisuje swoje hasło, nie jest zainfekowany jakimś złośliwym oprogramowaniem typu keylogger.

• Monitorowanie pomaga głównie w analizie pośmiertnej; nie zapobiega atakowi, ale pomaga określić, co się stało, jaki błąd został wykorzystany, aby można go było naprawić ... następnym razem.

• Tutaj nie jest czymś takim jak „gwarantowane bezpieczne wprowadzanie danych przez użytkownika”. Jest „dane wejściowe użytkownika, które zostały sprawdzone pod kątem zgodności z określonym zestawem reguł, co powinno oznaczać, że dane te mogą być wykorzystane w danej konstrukcji bez napotykania niewygodnych sytuacji”. Na przykład fragment tekstu może być „bezpieczny do umieszczenia w pliku HTML” (nie zawiera niektórych znaków specjalnych HTML, które uruchamiają zaawansowane przetwarzanie, takich jak „<” i „&”), ale w ogóle nie jest bezpieczny dla uwzględnienie w zapytaniu SQL (bezpieczne znaki HTML mogą zakodować całkowicie niezabezpieczone zapytanie SQL).

Aby dodać kilka punktów:

Uczyń hasło do konta administratora wystarczająco długie i skomplikowane (tj. teoretycznie hasła nie można złamać w rozsądnym czasie).

Długie i skomplikowane hasła są dobre, ale zwiększają prawdopodobieństwo, że zostaną zapisane. To samo dotyczy haseł, które trzeba często zmieniać. Zwłaszcza jeśli więcej niż jedna osoba potrzebuje hasła lub jest to hasło, które nie jest często używane.

Monitoruj cały ruch sieciowy przychodzący do plików administracyjnych.

Ataki eskalacji uprawnień sprawią, że będzie to bezcelowe, ponieważ zmiany będą wtedy wydawać się pochodzić z ruchu lokalnego, a nie z sieci. A zbyt intensywne monitorowanie otworzy nowe problemy. Exploity przepełnienia bufora są powszechne. Do licha, niektóre routery konsumenckie nadal dławią się wstrzymanymi próbami ruchu zatykającymi tabele połączeń.

Aby rozszerzyć warstwę ochrony z punktu 2 powyżej, monitoruj zmiany plików lokalnych (szczególnie te, które mają polecenia wymagające uprawnienia sudo).

Lepiej, ale ataki eskalacji uprawnień mogą pozwolić komuś na przesłanie pliku binarnego i dodanie do niego lepkich bitów suid / sgid. Nie będzie jej na liście plików do sprawdzenia.

Sprawdź poprawność wszystkich danych wprowadzonych przez użytkownika, aby zagwarantować, że wszystkie dane wprowadzone przez użytkownika są bezpieczne.

Ile wysiłku w to włożysz? Dezynfekcja danych wejściowych użytkownika nigdy nie jest w 100% skuteczna.

Zasadniczo chodzi o to, że niektóre rzeczy, które robisz, spowodują więcej problemów niż ich zaniechanie, zawsze można to obejść, po prostu staraj się robić wszystko, co w twojej mocy i mam nadzieję, że nie popełnisz głupawego błędu. Bądź jak środek dezynfekujący. Możesz zabić tylko 99% problemu.

„Można nie popełniać błędów i nadal przegrywać. To nie jest słabość, ale życie”. - Picard

Nie zdefiniowałeś, co oznacza włamanie na Twój serwer.

Pierwszym krokiem jest zdefiniowanie zakresu legalnego dostępu do systemu. Kim są użytkownicy i co system zapewnia użytkownikom wymagającym ochrony?

Jeśli system jest przeznaczony do bardzo specyficznej, ograniczonej funkcji (np. Do obsługi określonej aplikacji rozproszonej), a atakujący mogą uzyskuj dostęp do tego systemu tylko przez sieć, wtedy właściwie tylko ta aplikacja musi być bezpieczna, a także części systemu narażone na działanie sieci: karta LAN, jej sterownik i stos sieciowy.

Prawdziwe wyzwanie w bezpieczeństwie w systemie operacyjnym takim jak Linux jest to, jak sprawić, by system operacyjny był nie do złamania w sytuacji wielu użytkowników, gdy ludzie prawie w pełni wykorzystują system, mogą logować się do kont systemu operacyjnego i bezpośrednio uruchamiać aplikacje.

A system może mieć incydenty związane z bezpieczeństwem bez naruszenia bezpieczeństwa konta superużytkownika. Załóżmy, że masz system Linux, którego nie da się złamać. Jednak użytkownik joe instaluje niezabezpieczoną aplikację / home / joe / bin . Ta aplikacja otwiera złośliwy dokument, który wykorzystuje lukę w aplikacji, za pomocą której złośliwy kod uzyskuje wykonanie dowolnego kodu w kontekście bezpieczeństwa joe . Szkodliwy kod uszkadza dane joe , a także kradnie czas procesora z maszyny. (Mimo to nie można uzyskać uprawnień superużytkownika do wykonywania operacji, ponieważ maszyna jest „nie do zhakowania”).

Czy to jest zhakowane? Albo nie został zhakowany? A może z perspektywy użytkownika joe . Czy joe dba o to, aby root nigdy nie został naruszony podczas incydentu?

Jeśli ludzie (a przynajmniej twoi administratorzy) nigdy nie popełnili błędów, a programy komputerowe przez cały czas były w 100% wolne od błędów, to teoretycznie masz rację. Niestety, żadna z tych sytuacji nigdy nie jest prawdą i atakujący może łatwo zaatakować w tych punktach.

Nawet doskonale skonfigurowane oprogramowanie nie może działać tak, jak zostało skonfigurowane przez cały czas z powodu błędów. W odpowiednich warunkach może się zdarzyć, że oprogramowanie zrobi coś, czego nie powinno.

Podobnie, socjotechnika jest prawdopodobnie najpowszechniejszą formą hakowania. Nie ma potrzeby stosowania skomplikowanych środków technicznych, gdy możesz po prostu oszukać przeciwnika, aby dał ci to, czego chcesz. Samodzielne surfowanie po haśle, zdobycie rejestratora kluczy na komputerze, z którego korzysta administrator lub oszukanie administratora, aby uruchomił złośliwe oprogramowanie, to wszystkie możliwe sposoby, aby przemknąć się przez radar.

Możesz zrekompensować wiele to poprzez blokowanie serwera w pomieszczeniu bez połączenia z Internetem i zezwalanie administratorom na korzystanie z systemu tylko w pokoju ze strażnikiem przy drzwiach, a tak naprawdę działa wiele sieci rządowych o wysokim poziomie bezpieczeństwa, ale stawia to ogromne bariera dla użyteczności.

Ostatecznie bezpieczeństwo polega na równoważeniu użyteczności i ryzyka. Kroki, które nakreśliłeś, wymagają zbyt dużego ograniczenia użyteczności, aby można je było bezpiecznie zaimplementować, a zatem nie mogą działać samodzielnie w rzeczywistej sytuacji. Bezpieczeństwo to złożona i stale zmieniająca się dziedzina, która wymaga bycia na bieżąco z zagrożeniami, sprawdzania zabezpieczeń przed nowymi zagrożeniami i monitorowania pod kątem zagrożeń, które mogą się pojawić jako problemy 0-dniowe.

Od prawie dziesięciu lat próbuję tworzyć systemy kuloodporne. Musiałem poznać techniki projektowania zapewniające wysoką pewność (np. EAL7), tajne kanały, ataki wywrotowe itp. Szczerze mówiąc, większość projektantów systemów lub administratorów nie ma ani wiedzy, ani zasobów, aby całkowicie zabezpieczyć komputer przed znanymi atakami. Jest to prawie niemożliwe, biorąc pod uwagę ograniczenia biznesowe. Większość decyzji dotyczących bezpieczeństwa odzwierciedla kompromisy między kosztami, funkcjami, użytecznością, starszą kompatybilnością, profilami prawdopodobnych napastników itp.

Jeśli chcesz wiedzieć, oto jeden z moich uproszczonych zestawień na różnych poziomach i kwestiach bezpieczeństwa. (I to nie jest rozmiar książki 8). Został on skierowany do faceta, który uważał, że najlepsi programiści mogą tworzyć bezpieczne programy, ale możesz podrzędnym administratorem kodera i nadal te same wyniki. Baw się dobrze i ucz się lekcji, rzadziej powtarzając historię, jak robi to większość społeczności INFOSEC. ;)

http://www.schneier.com/blog/archives/2013/01/essay_on_fbi-ma.html#c1102869

To obserwuj Do góry w komentarzu jest mnóstwo linków, które śledzą historię, czynniki rządowe, wymagania programistyczne itp. Wymieniam również mnóstwo przykładowych systemów i procesów. Każdy może mieć wady, ale wzbudzać większe zaufanie niż przeciętny produkt.

http://www.schneier.com/blog/archives/2013/01/essay_on_fbi-ma.html#c1105156

System jest tak silny, jak najsłabsze ogniwo

To często powtarzane zdanie i należy pamiętać, że bez względu na to, jak silne jest hasło - jest to pojedynczy punkt niepowodzenia i brutal będzie w stanie przedrzeć się w pewnym momencie.

Ponadto, co by się stało, gdyby twój administrator systemu zdecydował się zaakceptować niezłą zapłatę za przypadkowe usunięcie zestawu plików?

Niemcy uważali, że zagadka jest nie do złamania i argumentowano, że ich poleganie na tej jedynej metodzie szyfrowania kosztowało ich wojnę - najgorsze jest poleganie na jednym systemie lub zasobach (ludzkich lub innych) możliwe przestępstwo przeciwko bezpieczeństwu.

Jest kilka aspektów ludzkich, które zwykle nie są przedstawiane, gdy zadaje się coś takiego.

1. Niektórzy ludzie dosłownie nie mają nic lepszego do roboty i próbują zhakować Twój system z czystej nudy .
2. Niektórzy robią to dla przyjemności (np. kilka białych kapeluszy). Białe kapelusze zazwyczaj nie są złe, ponieważ wielu z nich skontaktuje się z Tobą i powie „stary, dostałem się do Twojego systemu” i nie zrobi nic złego.
3. Niektórzy ludzie będą próbować zdobyć hasła użytkowników, aby wypróbować je w innych witrynach, np. kartach kredytowych. Pozują, by osiągnąć z tego ogromny zysk.
4. Niektórzy ludzie atakują serwer w celu zemsty. - Jane Berman powiedziała, że ​​mam kupę? JEJ SERWER ZADNIEJE!

Osoby, zwłaszcza w wieku 2-4 lat, mają zwykle niesamowitą pasję w dostaniu się do Twojego systemu. Czasami numer 1 zmienia się w 2-4. Firmy muszą płacić komuś za zabezpieczenie serwera, a powstrzymanie armii tego rodzaju ludzi przed atakowaniem go zajmuje dużo pieniędzy, badań i godzin pracy.

Może dlatego, że większość systemów i oprogramowania nie jest świadoma bezpieczeństwa. Bezpieczeństwo jest trudne do nauczenia, zrozumienia, a także aktualizacji (wiadomości, nowe kierunki ataków itp.).

Dlatego nie jest to robione w całości i szeroko. Na przykład nie ma takich norm bezpieczeństwa, jak normy ISO. Również dlatego, że jest to potencjalny rynek dla bezpieczeństwa krajowego (antywirusa).

Kiedy komputery staną się bardziej powszechne, być może któregoś dnia stanie się czymś, czym się zajmiemy. Jakaś przyszłość, w której na człowieka przypada około 100 lub więcej komputerów.

Jeśli naprawdę o tym pomyślisz, tak naprawdę nie polegamy na komputerach na tyle, aby martwić się o bezpieczeństwo w Internecie (przynajmniej tak myślę lub przynajmniej te części, które są krytyczne, są pod dobrą opieką).