Na Feedburner mam około 140 subskrybentów. Do tego dochodzi pewna grupa czytelników, którzy z dobrodziejstw RSS nie korzystają. Ciekawy jestem czy wśród czytelników są programiści (głównie chodzi mi o programistów tworzących aplikacje internetowe), a jeśli tak, to ilu. Czy programiści interesują się bezpieczeństwem? Jak wiele o nim wiedzą? Czy znają zagrożenia i wiedzą jakie powinni stosować środki zaradcze?
Moje odczucia są takie, że temat bezpieczeństwa jest traktowany mocno po macoszemu w procesie tworzenia oprogramowania. Inicjatywy takie jak Building Security In Maturity Model, Software Assurance Maturity Model czy Security Development Lifecycle to wciąż egzotyka. Chciałbym wiedzieć jak na ten temat zapatruje się "druga strona".
- 100% potrafi napisać prosty program w php
- 10-20% potrafi użyć gotowego frameworka albo rozszerzalnego CMSa - co znacznie poprawia bezpieczeństwo
- 5% wie co to jest SQL injection
- 1% rozumie konsekwencje bardziej zaawansowanych ataków typu XSS, cokolwiek-forgery, itd.
Oczywiście po studiach pisać aplikacje idzie więcej niż te 1%
Nie znam osobiście chyba żadnego programisty, który w większym stopniu interesuje się bezpieczeństwem. Niewielu zna chociażby podstawowe zagrożenia. W poprzednich (niewielkich) firmach, w których pracowałem wiedza ta była bliska zeru, w aktualnej świadomość jest o wiele większa (trochę wyższy poziom). Jednak ogólnie jest słabo ;-/
Czasem nawet w jednej organizacji niektóre zespoły były dobrze wyedukowane, a inne wcale. Potwierdza to podstawowe założenie ISO 27001, że pierwszą rzecząc, którą należy wykonać zanim zacznie się wdrażać jakiekolwiek techniki tam wymienione jest "obtain senior management support"
To może zmodyfikuje nieco pytanie - czy czytają mnie starsi programiści/team leader/kierownicy zespołu programistów? Jak kwestie związane z bezpieczeństwem wyglądają w ich zespole? Jaki poziom prezentują nowi pracownicy? Czy w jakikolwiek sposób poziom "nowych" w trakcie pracy jest podnoszony (szkolenia, pogadanki, rytualny lincz na "winnych" wprowadzenia błędów do kodu)?
Kapitalne rezultaty przynosi praca u podstaw - nawet godzinne szkolenie z paroma straszliwymi przykładami uczy czujności i pokazuje kierunki, w których goście mogą się już sami dokształcać (OWASP itd).
TYLKO ŻE... aby przeszkolić tych gości musisz mieć zgodę ich szefa. Aby nie traktowali Cię jak pana od BHP ich szef musi też traktować ten temat poważnie.
Stąd takie działania edukacyjny muszą zacząć się od szefów. Inna sprawa, że im wystarcza 15 minut z częstym cytowaniem Datalossdb.org
Można oczywiście mówić jacy to developerzy są nie dobrzy bo nie wiedzą - to fakt. Brak wiedzy w zakresie "security", a także "quality" jest i to jest fakt, nie chce z tym polemizować tylko pokazać inny problem.
Z drugiej strony są jednak klienci. Nawet ci duzi i świadomi (z bankami nie pracowałem) nie zamawiają ani "quality" ani "security", a przecież ktoś za to musi zapłacić. Firmy starają się jakoś przeżyć i obcinają różne koszty.... i jest jak jest. Z drugiej strony jak się kupuje samochód bez poduszek powietrznych to do kogo można mieć pretensje? Z "trzeciej" strony mamy tez doczynienia z nierzetelnością. Klient przez domniemanie zakłada, że system jest zrobiony zgodnie ze sztuką, płaci ile płaci, a dostaje niską jakość.
Inny problem to totalny brak komunikacji między ludźmi od security i od produkcji. Proponuje zrobić eksperyment i porozmawiać:
-o javie z ekspertami od security
-o Building Security In Maturity Model, Software Assurance Maturity Model
Od paru lat w dziedzinie produkcji oprogramowania mamy tendencje do lekkich metodyk w których nikt nie mówi o bezpieczeństwie. Mówi się o braku błędów o spełnianiu wymagań klienta itd. O security nie ma nic. Zostawianie tego na developerów nie jest dobrym pomysłem.
Właśnie wątek nierzetelności jest tutaj istotny. Wiele razy zwracałem uwagę, że w umowach z dostawcami często nie są zawierane żadne zapisy, które pozwolą egzekwować "bezpieczeństwo" od końcowego produktu. Problemem jest choćby zdefiniowane mierzalnych parametrów, których (nie)przejście wpływa na odbiór dostarczonego produktu.
Osoba od security nie musi być ekspertem w danej technologii. Problemy, z którymi się spotykam najczęściej nie wynikają ze specyfiki wykorzystanej technologii, tylko z niewiedzy. Brak walidacji, brak encoingu danych wejściowych, dynamiczne składanie zapytań SQL, "kontrola dostępu" poprzez ukrywanie/wyłączanie opcji w GUI aplikacji - to wszystko są kwestie praktycznie niezależne od wykorzystanej technologii.
Co do samego problemu z brakiem komunikacji, to się zgodzę. Często wygląda to tak, że przyjdzie bezpiecznik, coś tam pogada, programiści/produkcja dla spokoju posłuchają myśląc o zupełnie czymś innym, a potem i tak zrobią to po swojemu...
Mówienie o najlepszych praktykach jest skazane na porażkę w 100%. Opowiadanie o różnych włamaniach do różnych odległych portali - w 80%. Case study z bankiem będących bezpośrednim konkurentem klienta nieco przyciąga uwagę (np. wczoraj FSA ukarała HSBC $4m grzywną za niechlujstwo w ochronie danych) i z tego w ogóle należy zaczynać.
Bezpieczeństwo w rozumieniu menedżerów jest kosztem. Trzeba im pokazać, że nie jest kosztem tylko inwestycją, którą ponosi się po to, by nie ponieść straty. Tzn. wydajecie $300k po to, żeby nie wydać $3m na karę plus utrata reputacji.
Pokazanie (wymiernych) zysków z bezpieczeństwa również może być trudne, bo informacja o stratach obarczona jest dużym stopniem niepewności. Nie bardzo jest z czym się porównać i weryfikować szacunki.
W przypadku programistów przykładowym zyskiem może być zmniejszenie czasu poświęcanego na usuwanie błędów bezpieczeństwa. Ale by móc go w jakiś wymierny sposób ocenić, trzeba mieć informacje na temat zgłaszanych błędów bezpieczeństwa i czasu potrzebnego na ich usunięcie. Co więcej błędy bezpieczeństwa powinny być odróżnialne od innych błędów i, co najważniejsze, powinny być zgłaszane. I z tym wyszukiwaniem i zgłaszaniem błędów bezpieczeństwa może być pewien problem.