W jaki sposób duża firma popełnia błędy debiutanckie, które pozostawiają dziury w bezpieczeństwie? [Zamknięte]

Sony zostało ostatnio zhakowane za pomocą zastrzyku SQL, a hasła ich użytkowników były przechowywane jako zwykły tekst. To są błędy debiutantów. W takiej dużej firmie, jak to przechodzi QA? Jak nie mają lepszych zespołów niż wiedzieć lepiej niż to?

Sama wielkość firmy, która została zaatakowana przez hakerów, czyni to inaczej. Wpływa to na nas wszystkich, ponieważ któregoś dnia możemy znaleźć się w zespole odpowiedzialnym za coś takiego, a potem dostajemy siekierę. Jakie są zatem przyczyny tego zjawiska i jak im zapobiegamy?

Pierwszą rzeczą, jaka przychodzi mi na myśl, jest to, że są wystarczająco duże, aby wyhodować kilka warstw biurokracji. Oznacza to, między innymi, że nie masz już naprawdę inteligentnych programistów odpowiedzialnych za proces rekrutacji, co oznacza, że ​​tracą oni zdolność do eliminacji potencjalnych programistów i niekompetentnych pracowników QA. Co prowadzi do pisania złego kodu i wprowadzania go do produkcji, a wszyscy wiemy, co będzie dalej ...

Ponieważ programiści nie zostali poproszeni o przetestowanie tego, a miażdżąca kultura korporacyjna nie dała im wystarczającej swobody, by mogli poczuć etykę zawodową i poprosić o kolejne kilka tygodni na sprawdzenie podatności na zagrożenia. Lub nalegać, aby były bezpieczne od samego początku.

Ponieważ szef nie chciał spędzić kilku dodatkowych tygodni na testowaniu problemów bezpieczeństwa z ... jakiegokolwiek powodu. Dodatkowy bonus na koniec roku. Pojawienie się Johnsona z następnego działu. Prawa do przechwalania się. Obowiązek wobec firmy. Lenistwo. Nieufność do rady podwładnego.

Ponieważ wielki szef zażądał większych zysków i wypromował Johnsona nad Bobem, ponieważ jego liczba wyglądała lepiej niż żądanie lepszego produktu. Ponieważ jakość i bezpieczeństwo to trudne wartości do wyświetlenia w arkuszu kalkulacyjnym. Ponieważ korporacje istnieją, aby zarabiać pieniądze.

Takie rzeczy to systematyczny problem. Sprowadza się to do „bo są głupcami”.

Edytuj Programiści mogą uniknąć bycia ofiarną kozą, zauważając brak, zwracając się do swojego szefa. Albo zrobi właściwą rzecz i przygotuje plan, aby to naprawić, albo powie ci, żebyś to zignorował. Jeśli nie naprawi tego, zrób to oficjalnie, zapytaj o to e-mailem. W tym przypadku użyj słów kluczowych związanych z problemem, takich jak „podatność”, „zastrzyk”, „naruszenie bezpieczeństwa”. Rzeczy, które wyszukiwałby e-mail.

To przechodzi dolara. Teraz to odpowiedzialność twoich szefów. Jeśli jest to ważne, tak jak ludzie umrą, gdy to się nie powiedzie, przejdź nad głową i porozmawiaj z szefem. Możesz zostać zwolniony za samo przekazanie złotówki, i nadal możesz zostać zwolniony, nawet jeśli go przekażesz, ale jest to właściwe. Nie do końca tak poprawne, jak rozwiązanie problemu, ale blisko.

Im większa korporacja, tym bardziej osoby podejmujące decyzje są odpowiedzialne za rzeczywiste obowiązki.

Wiedząc, jak działają korporacje, projekt strony został prawdopodobnie zlecony jakiejś firmie konsultingowej wybranej na podstawie najniższej ceny za programistę. Ta firma z kolei zatrudniłaby grupę losowych ludzi na podobnych kryteriach, przy czym przeciętna osoba pozostała przy projekcie nie dłużej niż 3 miesiące, zanim zostanie przeniesiona na coś innego.

Jak ktoś popełnia błędy? Przez lenistwo, brak wiedzy, brak wiedzy specjalistycznej, praktyczność, brak procesu itp. Jak zapobiegamy błędom? Dzięki staranności, doświadczeniu, zabezpieczeniom itp. Ta sytuacja nie różni się kategorycznie od tysięcy małych błędów popełnianych przez każdego programistę; ma tylko inną skalę.

Czego możemy się z tego nauczyć? Niewiele.

Jednym z możliwych wyjaśnień jest przekrzywiona lista priorytetów. Wiele firm, z którymi współpracowałem, przywiązywało większą wagę do wprowadzania produktu na rynek niż do jakości produktu / kodu, który produkowały. Ten efekt jest podwojony, ponieważ nie tylko programiści są pospieszni do ukończenia, ale także dział QA (jeśli nawet mają). Zauważyłem również, że takie podejście zbiega się z przejściem do następnego produktu przed ukończeniem wcześniejszego, co jeszcze bardziej pogłębia problem.

Wspólnym mianownikiem w każdej z tych spółek było nietechniczne zarządzanie. Menedżerowie projektów, menedżerowie IT i menedżerowie produktu, w zasadzie każdy, kto ma wpływ na to, nad czym pracuje zespół programistów, są nietechniczni i nie rozumieją znaczenia tworzenia wysokiej jakości, bezpiecznego kodu. To jest coś, czego szukam podczas rozmowy z firmami. Kto sprawuje władzę nad azylem, więźniami lub lekarzami?

Nie zdziwiłbym się, gdyby coś podobnego, pogłębionego biurokracją, przyczyniło się do problemów bezpieczeństwa Sony i innych firm.

Ludzie pracują w dużych firmach, a ludzie popełniają błędy, wynikające z ignorancji, lenistwa, złych procedur, złej dokumentacji itp. Wielkość firmy wpłynie tylko na błędy, ponieważ może być ich więcej.