11:37
19/8/2015

Microsoft, jako firma tworząca oprogramowanie, poza samymi systemami i aplikacjami udostępnia (za darmo) zestaw praktycznych instrukcji, wskazujących jak bezpiecznie budować oprogramowanie niezależnie od języka programowania w jakim ono powstaje. Poznajcie (M)SDL — (Microsoft) Security Development Lifecycle, zbiór zaleceń, które pomogą firmom szybciej tworzyć bezpieczniejsze oprogramowanie.

Dlaczego każdy programista i manager powinien zapoznać się ze wskazówkami Microsoftu?

Bo przepis na zminimalizowanie liczby dziur w oprogramowaniu pochodzi z autopsji. Microsoft jak mało która firma, ma dużo do powiedzenia w tym temacie. Pamiętacie jak łatwo można było zaatakować Windows 95 i jak niewiele system ten posiadał zabezpieczeń przed atakami? Porównacie to z liczbą zabezpieczeń, jakie posiadają najnowsze systemy Microsoftu, np. Windows 10. Ten postęp, który był możliwy dzięki wdrożeniu “bezpiecznego cyklu życia oprogramowania“. A że droga Windowsa do obecnego stanu nie była wcale taka prosta, tym bardziej warto zobaczyć czego na przestrzeni ostatni lat nauczyli się programiści Microsoftu i jakie techniki projektowania, programowania i testowania polecają.

Czym jest Security Development Lifecycle?

SDL to proces tworzenia oprogramowania, który pozwala budować bardziej bezpieczne oprogramowanie, przy okazji redukując koszty. W skrócie: im więcej błędów uda się wyłapać w początkowych fazach powstawania oprogramowania, tym lepiej (taniej). Zależność tę przedstawia następujący wykres:

fot. isixsigma.com

fot. isixsigma.com

A dlaczego (M)SDL jest takie wartościowe? Bo przekazuje informacje, które mają nie dopuścić do powstawania błędów w tworzonym oprogramowaniu.

Microsoftowy SDL podzielony jest na 7 faz:

msdlc

  • Training. Bardzo ważne jest, aby programiści posiadali odpowiednią wiedzę dotyczącą błędów, jakie mogą popełnić w trakcie tworzenia oprogramowania. Znać język programowania, a umieć go używać w sposób bezpieczny to spora różnica. Z naszych doświadczeń wynika, że mało, który programista wie na czym polega modelowanie zagrożeń i jak poprawnie je przeprowadzić. Na szczęście jest wiele darmowych źródeł wiedzy dotyczących bezpiecznego programowania, jak i profesjonalne, komercyjne szkolenia z bezpiecznego tworzenia aplikacji (także mobilnych).
  • Requirements. Poprawne zdefiniowanie wymogów dla bezpieczeństwa i prywatności we wczesnej fazie budowy oprogramowania pomaga uniknąć wielu kosztownych decyzji (i przeróbek) w dalszych fazach. Warto też zdefiniować minimalne poziomy ryzyka, które jesteśmy w stanie zaakceptować w naszym projekcie. (M)SDL w tej fazie pokazuje uczy jak wykorzystywać tzw. “quality gates” i “bug bars” oraz jak badać wpływ oprogramowania na prywatność i oceniać które elementy projektu wymagają przeprowadzenia modelowania zagrożeń. Poprawnie wykonana analiza ryzyka, to jeden z kluczowych elementów definiujących bezpieczeństwo tworzonego oprogramowania.
  • Design. W ramach tej fazy m.in. można dowiedzieć się jak definiować powierzchnię ataku i redukować ryzyko jego wystąpienia — czyli jakie zabezpieczenia warto (i kiedy) wdrożyć. Wprowadzane są podstawowe zasady bezpieczeństwa, taka jak m.in. “zasada minimalnych przywilejów” czy też “defence in depth”.
  • Implementation. Piwo można otworzyć zębem i otwieraczem. W tej fazie podkreślane jest znaczenie dobrych i sprawdzonych narzędzi, które pozwalają nie tylko budować ale i zarządzać budową oprogramowania. Wprowadzane jest także pojęcie statycznej analizy kodu, czyli przeglądu kodu źródłowego pod kątem błędów i wykorzystania przez programistę starych, niebezpiecznych funkcji (API). Warto poświęcić chwilę na to, aby zastanowić się jak płynnie zintegrować tę automatyczną ochronę z procesem wprowadzania przez programistów kodu do repozytoriów. Na początku nie będzie łatwo (niechęć programistów i konieczność nauki powodów “odrzucenia” danego fragmentu kodu i ryzyk z nim związanych), ale w dłuższej perspektywnie takie podejście powoduje wzrost bezpieczeństwa tworzonego kodu i minimalizację błędów odkrywanych na klasycznych testach penetracyjnych, co oznacza mniejsze koszty.

  • Verification. Jeśli “fuzzujecie” swój kod, to możecie pominąć tę fazę. Nasze doświadczenia jednak pokazują, że o ile część z software housów wykonuje podstawowe dynamiczne testy bezpieczeństwa swoich aplikacji, to mało która firma jest w stanie stworzyć własny dedykowany fuzzer. A podczas fuzzingu znajdowanych jest dużo błędów — jeśli więc sami nie fuzzujecie swojej aplikacji, ktoś kto to zrobi, ma dużą szansę na odnalezienie w niej wielu błędów. I nie zawsze będzie na tyle “etyczny”, że da Wam o nich znać…
  • Release. Wydanie aplikacji bez planu reakcji na możliwe incydenty (tzw. Incident Response Plan) to ryzyko chaosu i dłuższego narażenia klientów na ewentualne ataki. To samo dotyczy braku wykonania kompleksowych testów penetracyjnych na finalnej wersji aplikacji (tuż przed jej udostępnieniem) oraz ostatecznego zweryfikowania przyjętych założeń co do modelu ryzyka, “quality gates” i “bug bars” zdefuniowanych w trakcie fazy 2.
  • Response. Każdy wolałby, aby stworzone przez niego rozwiązanie było wolne od problemów i błędów bezpieczeństwa. Praktyka pokazuje jednak, że nie jest to możliwe. Co chwilę odkrywane są nowe ataki i należy być przygotowanym na szybką reakcję, jeśli dany atak zagraża danym przetwarzanym przez nasze oprogramowanie. Kluczowa jest nie tylko szybkość reakcji, ale przygotowane zawczasu odpowiednie scenariusze postępowania, często wymagające kontaktu z podwykonawcami lub autorami zewnętrznych bibliotek.
Zwróćcie uwagę, że metodyka (M)SDL obejmuje problem całościowo i nie dotyczy tylko i wyłącznie technicznej części budowy oprogramowania, ale bierze pod uwagę także przygotowanie do samego tworzenia oprogramowania, tj. szkolenia oraz obsługę “powydaniową”, m.in. wskazując jak poprawnie reagować na zgłaszane błędy.

Dużo narzędzi pomocniczych

Poza samymi wskazówkami, Microsoft udostępnia dla prawie każdej z faz szereg narzędzi stworzonych specjalnie dla osób wdrażających SDL w swojej firmie. Jest program ułatwiający analizowanie powierzchni ataku, modelowanie zagrożeń a także kilka mini-fuzzerów (np. do testowania wyrażeń regularnych).

Gotowy? Do dzieła!

Chętnym do wdrożenia microsoftowego SDL na start polecamy Self Assesment Guide. Ten kwestionariusz pozwoli wam ocenić “dojrzałość” waszego procesu tworzenia oprogramowania i wskaże, nad czym warto jeszcze popracować.

Firmom, które pracują w Agile, i są przerażone “rozmiarem” (M)SDL-a, na pewno przyda się ta praktyczna ściągawka, która pokazuje jak zaimplementować wskazówki w podejściu agilowym.

Na stronach poświęconych (M)SDL znajduje się także bogaty w informacje dział FAQ.

Na koniec, dodamy od siebie, że nie zawsze (nie dla każdego projektu) warto wdrażać SDL Microsoftu od A do Z. W naszej opinii, każdy programista powinien jednak zapoznać się z (M)SDL — na pewno niektóre z jej elementów jest w stanie wdrożyć do nawet do niewielkiego hobbystycznego projektu, podnosząc tym samym jego bezpieczeństwo. Przekażcie więc linka do tego artykułu znajomym programistom i project managerom. A jeśli implementowaliście (M)SDL lub jej elementy (np. statyczną analizę kodu), dajcie znać w komentarzach, co sprawdza się u Was najlepiej.

Przeczytaj także:

20 komentarzy

Dodaj komentarz
  1. Mam nawet książkę (in pl) o SDLu w domu, szkoda że jest już nieco przestarzała. Ale best practices wiecznie żywe.Wydanie Microsoft Press (http://oto-ksiazki24.pl/cykl-projektowania-zabezpieczen-security-development-lifecycle-proces-tworzenia-znaczaco-bezpieczniejszego-oprogramowania–p191784 ), nie wiem czy jeszcze to sprzedają.

  2. Zapomnieli dodac zeby korzystac z otwartego zrodla, ktore jako jedyne gwarantuje pelna kontrole nad wlasnym oprogramowaniem.

    • @Zdzichu: co ma piernik do wiatraka?
      My tu mowimy o bezpieczenstwie, tylko otwarty kod hardware&software gwarantuje Ci pelna kontrole nad wlasnym produktem, to niezaprzeczalny fakt!
      Oczywiscie wygodniej jest programowac na xbox’a, ale wtedy microsoft decyduje ile backdoor’ow sprzetowych i software’owych znajdzie sie w Twojej aplikacji.

      Co do wspomnianego propagandowego modelu biznesowego to jak wyjasnic zjawisko z nowym windows10? Czyzby microsoft wzorowal sie na “niewypale” z red hat i jego fedora OS?

  3. Pracuje nad wdrożeniem u siebie w fabryce Open SAMMa. Czy ktoś ma jakieś doświadczenia pozwalające na porównanie Open SAMMa z Micro$oft SDL? Dopiero zaczynam i nigdy mi jakoś z wielkim M nie było po drodze, ale w tym przypadku bez sensu jest się na siłę opierać. Na razie Open SAMM bardzo mi się podoba ale może jest coś i w (M)SDL co warto by wykorzystać, a może Open SAMMa bije na głowę? Nie mam czasu na głębokie wbijanie się w oba (jest przynajmniej jeszcze kilka innych możliwości, BSIMM bodajże między innymi) bo oprócz tego mam swoją normalną robotę czarnucha do odwalenia. Gdyby ktoś mógł choć w kilku żołnierskich słowach naświetlić temat.

  4. Szkoda że dziś “aplikacja” to jest www … mniemam że SDL jest tam przydatny, ale Microsoft zaliczył faila nie na polu ‘web’ ale na polu aplikacji ‘exe’

    Sporo tam jest racji, ale nie wyobrazam sobie by aplikacja typu: Faktura2003 byla lub musiała byc ‘testowana’.

    Aplikacje dekstop nie maja problemu z ‘security’ jako tako, z racji tego zeby to robic to sa koszta, a takowe ograniczają się do:

    Będzie krak na software lub DRM?

    Web to web, tam jest syf kiła i mogiła, każdy pisze co mu PHP przyniesie, i to nie jest ‘aplikacja’ a jeżeli już: ‘aplikacja web’ to tak to należy klasyfikować.

    • Zwyczajne aplikacje, typu Faktura2015, trzeba testować. M.in. czy instalacja nie miesza w uprawnieniach folderów, czy pola wartości zabraniają na wpisanie głupot, upewnić się gdzie przetrzymywane są dane i kto ma do nich lokalny dostęp (admin+twórca danych, czy wszyscy użytkownicy systemu). To tylko przykłady, a wektorów ataku na aplikacje desktopowe jest znacznie więcej. Ochrona aplikacji na pewno nie ogranicza się do obrony przed stworzeniem cracka czy złamaniem DRM.

    • “Aplikacje dekstop nie maja problemu z ‘security’ jako tako (…)”, tia… zwłaszcza Outlook, Office, Adobe Reader, Explorer, Faktura, Rachmistrz, Płatnik, Janosik… – po co komu bezpieczenstwo tych aplikacji desktopowych?
      Ciekaw jestem poziomu @skitter ‘stwa w rodzimym przemyśle softwarowym.

  5. SDL funkcjonuje od dawna – dla tych, którzy pracują ITSec, InfoSec, itp. gdzie zaangażowane są technologie MS, znają to podejście i nie jest ono żadnym novum…

  6. Skiter, nie tworzysz oprogramowania, prawda? Oprogramowanie, które nazwałeś “exe”, wymaga takiego samego procesu Q&A, jak każde inne – i poświęca się na to ogromne nakłady czasowo finansowe.

  7. Kiedyś interesowałem się tematem i muszę przyznać, że dla typowej aplikacji webowej pełny SDL to przerost formy. Istnieje dużo lżejszych rozwiązań które są tańsze i bardziej nastawione na efekt jak np. OWASP ASVS. Jak będę pisał system operacyjny, to zastanowię się nad MSDLem. Rzadko kiedy potrzebujemy działa tego kalibru.

  8. MSDL i system operacyjny, ubawiłeś mnie , haha.

  9. Windows 10 za swoją licencję i Microsoft za politykę prywatności nie zasługuje na miano profesjonalisty w temacie. Jeżeli jest szpiegostwo – jest backdoor – a to już samo przez się mówi, że niebezpieczne.

  10. Ich najnowsza świetna przeglądarka vs chrome (który podobno je tonę ramu)
    na Edgu odpalony stream twitch (jakosć mobile) od rana na chrome to samo (jakość source)+ otwierane dodatkowe karty od czasu do czasu, nie jest to pierwszy raz.

  11. ALe oni przecież nie programują bezpiecznie :P

  12. Piszę programy na mikrokontrolery głównie w języku C i zawsze staram się robić to bezpiecznie , jeszcze nie udało mi się puścić z dymem jakiegoś egzemplarza przez źle działający program. Elektrostatyką owszem , załatwiłem już kilka sztuk :D Nie chce mi się przekopywać przez “makulaturę mikrosoftu” ale wątpię czy zawarte są tam jakieś wskazówki co do zastosowania zabezpieczeń przed niebezpiecznymi ładunkami elektrostatycznymi :D

  13. Tak, to prawda, kto jak nie Microsoft może mówić o dziurach w informatycznym oprogramowaniu, jednakże co tyczy się rozwiązań, póki co nie jest to firma godna polecenia, dlaczego? Bo oprogramowanie z tej stajni nadal jest dziurawe, po za tym mam dosyć ciągłego odpowiadania na głupie pytania typu, czy na pewno Ty to jesteś Ty? itp. Od kilkunastu lat używam linuksa i jestem z niego zadowolony, wszystko w zasadzie robię od razu i rzadko zdarzają się jakieś niespodzianki. Tak więc można napisać dobre oprogramowanie bez używania podsystemów sprawdzania tożsamości wiecznie pytającego się o to samo. Linux górą :D

    • Te Janusze zawsze głupie xD

      Dekstopowe Linuksy to nic nieznaczące systemiki. Dystrybucje serwerowe miewają nie lepsze problemy, niż Windows. To tylko kwestia popularności. A jeśli myślisz, że da się OS napisać bez błędów, to tylko widać, że g**o się znasz na inżynierii oprogramowania.

  14. Tak! Bierzcie przykład z Microsoftu! To największa firma popełniająca fatalne błędy w programowaniu daje ludziom rady co do programowania? To tak jak iść leczyć się do chorego lekarza! To tak jak brać rady na temat bogactwa od biedaka, który nic nie ma! Paranoja!

    • Rzeczywiście, shellshock i heartbleed mocno dotyczyły Windowsa…

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.