potrzebne jest jedno i drugie. też przecież nie jesteś za bezkarnością włamywaczy.
Ale przecież karność istnieje. Ściganie jest utrudnione przez indolencję operatorów sieci. Skoro Sony potrzebowało 2-3 dni, żeby się zorientować, że miał miejsce włam a dalszy tydzień był potrzebny by zrozumieć co skradziono, to jasne, jest to standard, ale... przeraźliwie smutny standard. Firmy nie dbają o bezpieczeństwo, nie znają się na nim, nie logują masy rzeczy, które się dzieją na serwerze, nie czuwają nad stanem własnej infrastruktury, itp.
W małej firmie, w której pracuję, jak "bezkarnie" odpalę zapytanie na produkcyjnej bazie, i będzie się ono wykonywało 30sekund+, to mam gwarancję, że w przeciągu kilku minut na komunikatorze admin spyta mnie co robię. Jak rośnie log transakcyjny to mam nalot z pytaniem co to wywołało. Monitorowane są zmiany w plikach na serwerach, zachowanie bazy i masa innych rzeczy. Jasne, to nie uniemożliwi włamania (nic nie uniemożliwi!), ale utrudni je lub przynajmniej ułatwi namierzenie delikwenta. Jeśli stać na coś takiego małą firmę, to stać na to Sony. I my praktycznie nie używamy custom softu do monitoringu, bo większość tego typu rozwiązań dostępnych jest OOTB z każdym sensownym softem. Wystarczy tego softu użyć. Naszym największym grzechem w tej chwili jest to, że hasła są tylko raz hashowane. Zamierzamy to niebawem zmienić, żeby uczynić ataki siłowe niepraktycznymi. Dalej: mimo iż email i nick nie są w rozumieniu prawa danymi osobowymi, usuwamy te informacje z bazy na życzenie użytkowników (którzy przeważnie twierdzą, że to są dane osobowe).
Jest masa rzeczy, których najwyraźniej skoszone ostatnio firmy nie robią. Część tych rzeczy wiem z doświadczenia Microsoft robi (i robi dobrze): audyty, logowanie, kopie bezpieczeństwa i masa innych rzeczy są kompletnym minimum tego, co się robi. W przypadku usług około-Live wymagania są dużo wyższe od czasu, kiedy LiveID (wtedy jeszcze Passport) zaliczyło prawniczą wpadkę w materiałach promocyjnych (reklamowanie czegoś jako "nie do złamania" to baaaaaardzo zły pomysł ;]). Z drugiej strony usunięcie konta jest utrudnione i MS powinien to naprawić. EIB łamie też reguły dotyczące współpracy z partnerami i np. rejestracji domen, ale to musi się skończyć (jeśli się jeszcze nie skończyło), bo ludzie wewnętrznie także na to narzekają.
a to, że oszczędza sie na audytach bezpieczeństwa, to jest kwestia indywidualna każdego przypadku i też nie można wszystkiego wrzucać do worka "źle napisane". jasne, dziecinny SQL Injection to jest problem po stronie dostawcy usługi. ale już na zaawansowany social hacking silnych nie ma. z samego "włamano się do xxx" nie ma więc automatycznie wniosku "xxx jest źle zabezpieczone".
Żaden z ostatnich włamów nie korzystał z social hackingu. To były SQLi, file infection (amerykański senat) i atak brute force na URLe (Citi). "Dziury" w ludziach wychodzą dopiero w drugiej fali, kiedy po zebraniu danych z serwerów następuje atak na cele wykorzystujące to samo hasło w różnych miejscach. Ale to jest drugorzędny problem. Ile dużych firm używa bcrypta? Sądzę, że zero. Ile ma CSO, który wie co to bcrypt? Może kilka. Problemami podstawowymi są legacy code (np. shit pisany w PHP bez użycia sensownego frameworka - czyli przez czasami Rails i MVC albo dojrzałości Zenda) i niekompetencja ludzi "decyzyjnych", którzy sądzą, że sieć jest "łatwa". Nie jest.
włamywacz musi wiedzieć, że za włamanie grozi surowa kara. a to czy przy okazji wyleją inżynierów odpowiedzialnych za zabezpieczenia i/lub menedżera który oszczędzał na audytach, to jest osobna kwestia.
Ale grozi. I co z tego? I jak tę karę wykonasz na włamywaczu wspieranym przez rząd X? Leczy się źródło choroby a nie objawy.
a odpowiadając na Twoje pytanie - dobrze opłacany pracownik, który w dodatku ma czas, może napisać WSZYSTKO porządnie. problem jest wtedy kiedy kowal zawinił, a Cygana powiesili - tu: management tnie koszty, a opinia jedzie po developerach.
Mimo wszystko sądzę, że tu częściej niż o koszty chodzi o zwykłe know-how. Dam Ci przykład z Google, do którego kumpel przeszedł z MS (po czym wrócił). Pracował nad Chrome, kiedy jeszcze projekt był tajny. Chrome silnie bazuje na COM/COM+, którego kumpel jest niekwestionowanym ekspertem (w MS są może ze trzy osoby, które wiedzą więcej niż on na ten temat). Niestety, team który został zebrany do tworzenia Chrome uznał, że pewne rzeczy są prostsze, niż kumpel twierdził, że są. Na stwierdzenie, że pewne elementy architektury są exploitowalne usłyszał wprost: nie znasz się. Wyszedł chrome i dwa tygodnie później pojawiła się konieczność łatania dwóch dziur bezpieczeństwa w miejscu, które wskazał. Zawiniła nadmierna pewność siebie i brak rzeczywistego know-how. Jak programista sądzi, że jest supermanem i ma wpływ na kształt softu, to dzieją się straszne rzeczy.