Szczerze mówiąc, staramy się nie przechodzić przez twoją bazę kodu, staramy się pisać narzędzia, aby to dla nas zrobić.
Po pierwsze teoria. Bezpieczeństwo jest wymogiem systemu oprogramowania, więc podobnie jak inne wymagania (funkcjonalność, użyteczność, dostępność, wydajność itp.) Należy je rozpatrywać na każdym etapie przepływu pracy inżynierii oprogramowania, od gromadzenia wymagań po wdrożenie i utrzymanie. Rzeczywiście jest to możliwe i istnieją wskazówki, które mogą pomóc zespołom projektowym w tym zakresie. Mimo że pracuję głównie z programistami iOS, mój ulubiony opis „bezpiecznego cyklu życia programowania” pochodzi od Microsoft Press .
W tym modelu bezpieczeństwo aplikacji rozpoczyna się, gdy próbujemy uzyskać wymagania od naszych użytkowników. Musimy odkryć ich obawy dotyczące bezpieczeństwa i prywatności, co nie jest łatwe, ponieważ jesteśmy ekspertami, a nie użytkownikami, a jeśli rozumieją swoje wymagania bezpieczeństwa, może im być trudno je wyrazić. Musimy także dowiedzieć się, na jakie ryzyko narażone będzie oprogramowanie podczas wdrażania i jaki poziom ryzyka jest akceptowalny.
Projektujemy naszą aplikację z myślą o spełnieniu tych wymagań. Piszemy kod z myślą o spełnieniu tych wymagań i uniknięciu dodatkowego ryzyka związanego z błędami bezpieczeństwa na poziomie kodu. Testujemy oprogramowanie, aby upewnić się, że nasz model jego bezpieczeństwa jest zgodny z tym, co naprawdę zbudowaliśmy, a następnie wdrażamy oprogramowanie w sposób zgodny z założeniami dotyczącymi środowiska, które zaprojektowaliśmy. Wreszcie zapewniamy wsparcie i konserwację, które pomagają użytkownikowi obsługiwać oprogramowanie w sposób zgodny z ich wymogami bezpieczeństwa i które pozwalają im (i nam) reagować na nowe zmiany w prezentowanym ryzyku.
Ok, tyle dla teorii. W praktyce , z powodów, które są bardzo dobrze wyjaśnione (choć nietechnicznie) w geekonomii i które są głównie spowodowane motywacją firm programistycznych, większość powyższych rzeczy się nie zdarza. Zamiast tego otrzymujemy to. Programiści:
- zatrudnić ochroniarza lub galę, aby byli obecni, kiedy licytują kontrakt, aby pokazać, że „dostają” ochronę.
- pisać oprogramowanie.
- zatrudnij ochroniarza lub osobę odpowiedzialną za weryfikację oprogramowania przed wydaniem, rozwiązując wiele problemów, które pojawiły się w kroku 2.
- załataj wszystko inne po wdrożeniu.
Więc tak naprawdę większość osób zajmujących się bezpieczeństwem aplikacji , tak jak mówisz, znajduje błędy. To naprawdę świetny przegląd kodu, ale jest to wysoce skoncentrowany przegląd kodu przeprowadzany przez ludzi, którzy są ekspertami w rodzaju błędów, których szuka ta recenzja, więc nadal jest cenna pomoc zewnętrzna. Jest to oczywiście ogólna zasada: zawsze poproś kogoś o sprawdzenie, kto nie był zaangażowany w zrobienie tego.
Jeśli zaakceptujemy powyższe jako prawdziwe, oznacza to, że osoby podejmujące decyzje zakupowe mogą zrównać „zdolnego ochroniarza” z „znajdowaniem wielu błędów”. Ci, którzy zmuszą komputery do pracy za nich, znajdą więcej błędów niż ci, którzy tego nie robią, więc oczywiście polegają w dużej mierze na narzędziach do analizy statycznej i będą starali się spędzać więcej czasu na rozszerzaniu narzędzi niż na kodowaniu konkretnych problemów dla konkretnych klientów. Następnie dochodzimy do wniosku, że osoby zajmujące się bezpieczeństwem aplikacji częściej piszą narzędzia do odczytu kodu niż do odczytu kodu.
** Ostrzeżenie: pozostaje tylko opinia i spekulacja **
Rzeczywistość jest zepsuta. Zauważysz, że teoria bezpieczeństwa oprogramowania polegała na identyfikacji i reagowaniu na ryzyko polegania na systemie oprogramowania, podczas gdy praktyka polegała na znalezieniu jak największej liczby błędów. Pewnie, że to jeszcze zmniejszy ryzyko, ale tylko jako efekt uboczny. Punkt gry stał się mniej ważny niż „wygrana”, więc zasady zostały zmienione, aby ułatwić wygraną.
Co możesz zrobić jako programista? Zagraj w grę według jej oryginalnych zasad. Znajdź kogoś w swoim zespole (najlepiej faktycznie w swoim zespole, a nie kontrahenta, aby zmotywowani do zapewnienia długoterminowych rezultatów zamiast szybkiej wygranej), który rozumie znaczenie bezpieczeństwa i wyszkoli z nich bejeezus. Powierz tej osobie odpowiedzialność za kierowanie zespołem w zapewnianiu kompleksowego bezpieczeństwa opisanego na początku mojej odpowiedzi.
Również dać tej osobie uprawnienia do realizowania . Jeśli projekt nie wyraża wymagań bezpieczeństwa, należy go zmienić. Jeśli implementacja nie spełnia wymagań bezpieczeństwa, nie można jej zwolnić . Twój pracownik ochrony może wykonać wyrok, ale należy mu zezwolić na działanie w oparciu o ten wyrok. Zdaję sobie sprawę, że może to zabrzmieć jak ochroniarz, mówiąc: „Bezpieczeństwo OMFG jest najważniejsze”, ale nie o to mi chodzi. Jeśli twój produkt również nie spełnia wymagań funkcjonalności, użyteczności lub wydajności, nie powinieneś również wypuszczać tego produktu.
Dlaczego chcesz to zrobić? Powinno być taniej: wszyscy widzieliśmy (i prawdopodobnie cytowaliśmy za tanie +10 powtórzeń) tabelę Code Complete, w której defekty stają się droższe, im później je naprawisz, prawda? Wady bezpieczeństwa są również wadami. Zgodnie z rzeczywistymi zasadami gry większość z nich to problemy z wymaganiami, które są ustalone w zakresie konserwacji. Czy to jest tanie?
Ok, co teraz może ja jako broń bezpieczeństwa dla niemowlęcia z tym zrobić? Okazuje się, że mogę również odmówić gry według zmienionych zasad. Mogę powiedzieć programistom, że chodzi przede wszystkim o zmniejszenie ryzyka, że można to zrobić na każdym etapie, a następnie mogę im pomóc.