O tym, jak ważne jest, by security rozumiało potrzeby biznesu i w konsekwencji pomagało mu, a nie blokowało, mówił w swoim case study, prezentowanym podczas sesji strategicznej Security Excellence - Michał Wierucki – „Zip”, CSO w Allegro. Wyjaśnił, jak poprzez pokazywanie wartości dodanej do Security przekonywać do siebie IT i biznes, a dzięki komunikacji opartej na budowaniu zaufania nie tracić czasu na spory i udowadnianie swoich racji. Pokazał, jak zautomatyzowanie testów bezpieczeństwa może w praktyce sprawić, że security nie będzie postrzegane przez developerów jako przeszkoda, którą trzeba ominąć.
REKOMENDACJE
Świat się szybko zmienia, dużo dzieje się choćby w chmurze, użyciu sztucznej inteligencji, etc. Jeśli biznes będzie chciał coś nowego wykorzystać, to rola bezpieczeństwa nie jest zniechęcanie do tego, mówienie - nie możecie tego zrobić, to zbyt niebezpieczne. Zamiast tego, bezpieczeństwo musi wskazać, co musi być zrobione, aby nowe rozwiązanie nie niosło ze sobą nieakceptowalnego ryzyka - mówił Michał Wierucki
Tworzy to taką relację, że ludzie nie boja się do nas przychodzić, gdy coś „nabroili”. My ze swej strony zyskujemy wiedzę o wszystkich incydentach i możemy się przed kolejnymi lepiej zabezpieczyć, które przy innym podejściu byłyby zatajane i by się eskalowały.
Przykładem może być wdrożenie uwierzytelniania wieloskładnikowego. Z jednej strony my potrzebujemy MFA, z drugiej strony biznes chciałby mieć dostęp do wszystkiego po jednym kliknięciu. Dlatego trzeba wykazać, że MFA jest koniecznością, wyjaśnić jakie ryzyka są niwelowane i wybrać taki model MFA, który będzie łatwy i intuicyjny dla użytkowników - podsumował Michał Wierucki.
PRAKTYKA - projekt odebrana praw lokalnego admina
Jak to wygląda w praktyce, pokazał przeprowadzony jakiś czas temu w Allegro projekt odebrania praw lokalnego admina. O ile kiedyś nie było wielu ograniczeń, to w pewnym momencie trzeba było stwierdzić, że posiadanie uprawnień lokalnego admina niesie zbyt duże ryzyka. Po otrzymaniu zielonego światła do zarządu określono, jakie mogą wystąpić problemy w wyniku tej operacji. Chciano uniknąć sytuacji, w której ludzie stwierdzą, że w nowych okolicznościach nie da się pracować. Ruszyła duża akcja informowania pracowników, jaki jest cel działań i jakie korzyści powinny one przynieść, jakie ryzyka zostaną ograniczone. Starano znaleźć się takie rozwiązanie, które nie będzie blokować pracowników a jednocześnie nie będzie generowało dużo więcej manualnej pracy po stronie IT Supportu. W wyniku tego zdecydowano się uruchomić system klasy EPM, by proces mógł przebiec w sposób jak najbardziej bezbolesny i automatyczny.
Kolejnym etapem było przeprowadzenie PoC, dla małych zespołów, w czasie, gdy nie było największego obłożenia pracą oraz żadnych krytycznych czynności do przeprowadzenia (robienie testów w dziale HR podczas przygotowywania wypłat, lub w dziale finansowym przy okazji zamykania miesiąca nie byłoby dobrym rozwiązaniem). Po wprowadzeniu ograniczeń dla „nietechnicznej” części firmy przyszła kolej na IT, czyli ludzi, ze strony których można się było spodziewać największych „protestów”.
Rozmowy o zmianie rozpoczęto od najaktywniejszych, najbardziej zaangażowanych programistów – ustaliliśmy, iż dopóki nie stwierdzą, że w danym setupie da się pracować, nie odbierzemy admina w technologii, co było dość ryzykownym posunięciem. Okazało się jednak, że po kilku miesiącach i oni przyznali, że da się pracować bez uprawnień lokalnego admina. Ułatwiło to wprowadzenie ograniczeń w developmencie i ostatecznie całej firmie.
LESSONS LEARNED SPOŁECZNOŚCI SECURITY EXCELLENCE
Więcej informacji o programie: https://www.cionet.com/security
These Stories on CIONET Poland
No Comments Yet
Let us know what you think