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

• To zarząd podejmuje decyzje dot. strategii security, ale powinny być one poprzedzone przedstawieniem przez zespół bezpieczeństwa wszelkich opcji wraz z towarzyszącymi im ryzykami oraz rekomendacji. 
• Za bezpieczeństwo nie jest odpowiedzialny tylko zespół ds. security, ale cała firma - od prezesa do magazyniera. Zespół od bezpieczeństwa jest od tego, żeby mówić co i jak zrobić, żeby było bezpiecznie. Zwracać uwagę na to, jakie rzeczy są pożądane, a jakie nie.  
  

Ś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

• Kulturę buduje się poprzez współpracę i komunikację. W przypadku incydentu nie szukamy winnych, tylko staramy się zrozumieć, jaki był problem, aby wyeliminować jego przyczynę.  

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.

• Zaufanie zdobędziemy poprzez otwartość i proponowanie kilku opcji, a nie wskazywanie  jedynego słusznego rozwiązania problemu.  Jednocześnie trzeba jasno przedstawić zależności  -  jeśli zostanie wybrana opcja A, to wiąże się to z takimi zyskami i ryzykami, a w przypadku opcji B zyski i ryzyka są inne. 
• Przy rozbudowanym developmencie, takim jak ma Allegro, nie da się uniknąć szorstkiej przyjaźni pomiędzy security a programistami.  Wymuszanie czegoś siłą bez wytłumaczenia konieczności wprowadzenia tego i w efekcie zdobycia akceptacji, spowoduje tylko niepożądane zachowania z punktu widzenia security. Najważniejsze, aby przekonać do swojej racji odpowiednio argumentując jakie korzyści da nam dane rozwiązanie.
• Wdrażając rozwiązania security warto znaleźć „złoty środek” pomiędzy sec, IT i biznesem - doprowadzić do sytuacji, gdy z jednej strony poziom ochrony będzie akceptowalny, a z drugiej zostanie zachowana elastyczność bez ograniczania biznesu. Ważna przy tym jest argumentacja, dlaczego coś musi być zrobione.
  

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