Securing

Następnym z pytań jakie wraz z Sebastian Obara dostaliśmy na warsztatach modelowania zagrożeń podczas tegorocznej edycji CONFidence Conference była kwestia: ❓ Kto jest właścicielem modelu zagrożeń (assetów, mitygacji itd.)❓ Assety 🗃 Najprostsza odpowiedź jest w kwestii assetów - czyli zasobów. Z mojego doświadczenia odpowiedzialność za komponenty aplikacyjne i infrastrukturalne jest zazwyczaj dobrze określona - są zespoły odpowiadające za dany mikroserwis, API, aplikację czy konto AWS. Czasem trafiają się porzucone sierotki, legacy aplikacje, które jakoś działają, ale specjalnie nikt o nich za dużo nie wie i nie chce przy nich zbytnio grzebać. Z perspektywy zagrożeń, a bardziej nawet z perspektywy atakującego 😈 wygląda to kusząco z dwóch powodów: 1️⃣ Stare aplikacje to stary kod – czyli stare biblioteki i znane podatności  2️⃣ Stare aplikacje mogły nie być testowane pod kątem bezpieczeństwa w ogóle lub dawno, czyli mogą zawierać podatności.   Model 📄 Z perspektywy diagramu czy dokumentu właściciel nie ma znaczenia. Problem zaczyna się wtedy, gdy określamy sobie, które zagrożenia akceptujemy, a które mitygujemy. Z mojego doświadczenia często nie jest to określone. Zespół deweloperski chce, aby bezpieka to ogarnęła, bezpieka (jak już jest) ma często roboty po kokardkę i chce maksymalnie delegować odpowiedzialność na programistów (to słuszny kierunek, bo kilku ludzi od bezpieczeństwa nie opanuje aplikacji tworzonych przez kilkuset programistów). To, co polecam uczestnikom warsztatu w sytuacji, gdy nie wiedzą kto ma za to odpowiadać, jest eskalacja tematu w górę. Ktoś na końcu bierze pieniądze za jakość tego, co tworzymy i pytania o bezpieczeństwo w kontekście nadciągających regulacji będą padać coraz częściej. Mitygacje 🛠 Teraz dochodzimy do sytuacji, gdzie pojawi się jakieś zadanie otagowane SEC. Pasuje dać mu priorytet i w jakimś sprincie zrealizować. Znowu pojawia się pytanie, kto odpowiada za bezpieczeństwo i decyduje, czy to będzie zrobione czy będzie wisieć w nieskończoność. Tutaj uczestnikom polecam znowu pójść w górę hierarchii. Jak góra nie ma woli poprawiać, to z perspektywy programisty, który stworzył zadanie, nic więcej nie pozostaje. Ktoś powie, że tego nie robimy, więc zamykamy ticket z komentarzem kto i dlaczego tak postanowił. To moim zdaniem jest jedynym wyjściem. Może trochę dupokrytka, ale czasem tematy związane z bezpieczeństwem muszą dojrzeć (jak jest incydent, to dojrzewają szybciej 😅 ). W idealnym świecie zespół powinien odpowiadać za swoje mitygacje. Powinien nadać priorytet zgodnie ze swoim wyczuciem oraz zrealizować zadanie w takim samym trybie jak inne. Czemu zespół? Bo ma najlepszą wiedzę o tym, jakie jest zagrożenie, jak jest określone jego ryzyko i jak kosztowne jest jego zmitygowanie. Może i powinien się podpierać bezpieką, ale na końcu to jego odpowiedzialność. Jeśli podoba Ci się ta seria, zostaw informację zwrotną w komentarzu 👇 i dodaj mnie do obserwowanych 👁! 

Long time no see [me blogging]. But finally you can read my new post: *Multiple TCC bypasses via SQLite environment variables* where I even share my recently discovered RE trick 😁

Dziękujemy wszystkim uczestnikom za liczny udział w naszym wydarzeniu "#ModelowanieZagrożeń - #FlipperZero w atakach fizycznych" oraz za wyjątkową aktywność podczas dyskusji. Wasze zaangażowanie, pytania i otwartość na dzielenie się doświadczeniami i wiedzą były nieocenione. Szczególne podziękowania kierujemy do ☛ Michał Kłaput 👈 i Julia Zduńczyk. Cieszymy się wspólnie, że spotkanie spotkało się z tak pozytywnym odbiorem i że mogliście poczuć się jak wśród "swoich". Do zobaczenia na kolejnych meetupach OWASP® Foundation w #Krakow #OWASP #Poland   PS. Wojciech Dworakowski i Kuba Maćkowski - dzięki za zaproszenie! oraz Techie's Space za super miejsce na spotkanie 👏 PS2. Zdjęcie po 2 godzinach spotkania 👈 😱 nikt nie wyszedł 🔥 💪 wcześniej