Biorąc pod uwagę ostatnie wydarzenia związanie z wykradnięciem danych osobowych ponad 70.000.000 klientów firmy SONY, zastanawiam się nad bezpieczeństwem aplikacji internetowych?

Przy te okazji jak wygląda bezpieczeństwo aplikacji open source, również w kontekście dostępu do naszych danych biznesowych przez firmę oferującą aplikację open source? Ja w każdym razie nie spotkałem się w żadnej z umów licencyjnych na takie oprogramowanie z klauzulą mówiącą o ochronie danych klienta/ użytkownika aplikacji open source.

Pozdrawiam serdecznie

Jacek Suski
http://lean-soft.com

Witam!

Odnosząc się do wydarzeń związanych z Sony chciałbym zaznaczyć, że bezpieczeństwo systemów informatycznych zależy przede wszystkim od ich administratorów i polityki bezpieczeństwa prowadzonej przez firmę. W większości przypadków powodem "włamań" jest czynnik ludzki i prawdopodobnie też tak będzie jeśli chodzi o Sony.

Systemy na licencji Open Source są dużo bardziej bezpieczne niż rozwiązania zamknięte i nie jestem odosobniony w tej teorii. Wynika to z faktu, że ewentualne błędy są wykrywane momentalnie, a społeczność projektu sama sugeruje odpowiednie poprawki. W tym miejscu przytoczę również pewną wypowiedź:
„Im więcej par oczu obserwuje kod, tym mniej błędów pozostaje niewykrytych” – Eric S. Raymond, zwolennik otwartego oprogramowania, autor The New Hacker’s Dictionary.

Co do klauzul odnośnie ochrony danych w rozwiązaniach Open Source również one występują i uważam, że nie mają one żadnego związku z rodzajem licencji (otwartej czy komercyjnej). Wystarczy przyjrzeć się kilku poważnym projektom Open Source, a nie "studenckim" rozwiązaniom.

Pozdrawiam,
Marcin

eVolpe Consulting Group
marcin.rozanski@evolpe.pl
http://evolpe.plMarcin Różański edytował(a) ten post dnia 29.04.11 o godzinie 11:36

Marcin Różański:

Systemy na licencji Open Source są dużo bardziej bezpieczne niż rozwiązania zamknięte i nie jestem odosobniony w tej teorii. Wynika to z faktu, że ewentualne błędy są wykrywane momentalnie, a społeczność projektu sama sugeruje odpowiednie poprawki.

Jak dal mnie to nie do końca masz rację. To ze jakiś intruz nie ma dostępu do kodu źródłowego - choćby źle napisanej aplikacji - jest dużym zabezpieczeniem. Analiza kodu dla wprawnego włamywacza jest prawie jak otwarte drzwi. Tak więc był bym daleki od porównań Open Source - bezpieczne, komercyjne - niebezpieczne. Wszystko zależy od ludzi, podejścia do projektu itp.

Tomek P.:

Marcin Różański:
Systemy na licencji Open Source są dużo bardziej bezpieczne niż rozwiązania zamknięte i nie jestem odosobniony w tej teorii. Wynika to z faktu, że ewentualne błędy są wykrywane momentalnie, a społeczność projektu sama sugeruje odpowiednie poprawki.

Jak dal mnie to nie do końca masz rację. To ze jakiś intruz nie ma dostępu do kodu źródłowego - choćby źle napisanej aplikacji - jest dużym zabezpieczeniem. Analiza kodu dla wprawnego włamywacza jest prawie jak otwarte drzwi. Tak więc był bym daleki od porównań Open Source - bezpieczne, komercyjne - niebezpieczne. Wszystko zależy od ludzi, podejścia do projektu itp.

Gdyby było tak jak mówisz to serwery z zainstalowanymi systemami operacyjnymi z rodziny Linux (otwarty kod) nie miałyby racji bytu ze względu na bezpieczeństwo. Natomiast systemy operacyjne firmy Microsoft uniemożliwiałyby wykrycie i wykorzystanie błędu dzięki zamkniętym źródłom. Praktyka pokazuje, że jest zupełnie na odwrót. Dla wprawnego włamywacza dekompilacja aplikacji nie jest większym problemem natomiast sam fakt otwartego kodu nie pozwoli laikowi na przeprowadzenie włamania.

Nie chce w tym momencie generalizować, że otwarte systemy są bezpieczne, a komercyjne niebezpieczne. Z drugiej jednak strony nie zgodzę się ze stwierdzeniem, że systemy Open Source są jak otwarte drzwi, ponieważ jest to jeden z wielu mitów dotyczących tego typu oprogramowania.

Tak jak wspomniałem w swojej poprzedniej wypowiedzi system informatyczny jest na tyle bezpieczny na ile pozwoli na to jego administrator.

Pozdrawiam,
Marcin

eVolpe Consulting Group
marcin.rozanski@evolpe.pl
http://evolpe.plMarcin Różański edytował(a) ten post dnia 29.04.11 o godzinie 12:40

Marcin Różański:

Tomek P.:

Marcin Różański:

Jak dal mnie to nie do końca masz rację. To ze jakiś intruz nie ma dostępu do kodu źródłowego - choćby źle napisanej aplikacji - jest dużym zabezpieczeniem. Analiza kodu dla wprawnego włamywacza jest prawie jak otwarte drzwi. Tak więc był bym daleki od porównań Open Source - bezpieczne, komercyjne - niebezpieczne. Wszystko zależy od ludzi, podejścia do projektu itp.

Gdyby było tak jak mówisz to serwery z zainstalowanymi systemami operacyjnymi z rodziny Linux (otwarty kod) nie miałyby racji bytu ze względu na bezpieczeństwo. Natomiast systemy operacyjne firmy Microsoft uniemożliwiałyby wykrycie i wykorzystanie błędu dzięki zamkniętym źródłom. Praktyka pokazuje, że jest zupełnie na odwrót. Dla wprawnego włamywacza dekompilacja aplikacji nie jest większym problemem natomiast sam fakt otwartego kodu nie pozwoli laikowi na przeprowadzenie włamania.

To trochę inaczej wygląda - specyfika systemu linux - windows jest trochę inna Windows ma być prosty łatwy w obsłudze dla zwykłego człowieka co w penym stopniu determinuje pewne rzeczy związane z bezpieczeństwem. Inna sprawą jest to ze MS zlewa sobie zgłaszane błędy i często poprawki wychodzą za późno. Gdzieś widziałem taki artykuł dokładnie na temat wirusów i pytali się czemu tak jest że nie ma wirusów na Linuxy - odpowiedź była bardzo prosta - nie opłaci się ich robić gdyż jeszcze jest zbyt mały odsetek użytkowników Linuxów. Wirusy też powstają po coś - nie są to głupie prymitywne zabawki tylko wyrafinowane narzędzia. Z drugiej strony napędzają rynek Antywirusów i tak się to kreci.

A co do dekompilacji i reverse engineering to już nie jest takie proste i wymaga sporych umiejętności i znajomości tematu. Zależy też co się rozumie przez dekompilację.

Tak jak wspomniałem w swojej poprzedniej wypowiedzi system informatyczny jest na tyle bezpieczny na ile pozwoli na to jego administrator.

Myślę że użytkownicy też mają troch do powiedzenia ale jak najbardziej zgodzę się z tym że dobry administrator + dobry produkt (komercyjny czy open source) są wstanie zapewnić odpowiedni poziom bezpieczeństwa.

Jeśli chodzi o kwestie metod zabezpieczeń to zapraszam na mojego bloga -> http://www.beldzio.com/kategoria/bezpieczenstwo :)

Nie ma jednoznacznej odpowiedzi. Osobiście najwięcej problemu w aspekcie bezpieczeństwa sprawiły wtyczki open source. Jednakże widziałem już niejeden niedofinansowany projekt który również zawierał podstawowe luki w bezpieczeństwie. Bezpieczeństwo kodu wynika bezpośrednio z jakości oprogramowania a z tym zarówno w rozwiązaniach komercyjnych jak i open source bywa różnie.

To trochę inaczej wygląda - specyfika systemu linux - windows jest trochę inna Windows ma być prosty łatwy w obsłudze dla zwykłego człowieka co w penym stopniu determinuje pewne rzeczy związane z bezpieczeństwem. Inna sprawą jest to ze MS zlewa sobie zgłaszane błędy i często poprawki wychodzą za późno. Gdzieś widziałem taki artykuł dokładnie na temat wirusów i pytali się czemu tak jest że nie ma wirusów na Linuxy - odpowiedź była bardzo prosta - nie opłaci się ich robić gdyż jeszcze jest zbyt mały odsetek użytkowników Linuxów. Wirusy też powstają po coś - nie są to głupie prymitywne zabawki tylko wyrafinowane narzędzia. Z drugiej strony napędzają rynek Antywirusów i tak się to kreci.

A co do dekompilacji i reverse engineering to już nie jest takie proste i wymaga sporych umiejętności i znajomości tematu. Zależy też co się rozumie przez dekompilację.

Tak jak wspomniałem w swojej poprzedniej wypowiedzi system informatyczny jest na tyle bezpieczny na ile pozwoli na to jego administrator.

Myślę że użytkownicy też mają troch do powiedzenia ale jak najbardziej zgodzę się z tym że dobry administrator + dobry produkt (komercyjny czy open source) są wstanie zapewnić odpowiedni poziom bezpieczeństwa.

panie tomku, zapytam krotko i twierdzaco. czy wie pan co to jest za jezyk programowania Assembler ?! i co to sa za narzedzia debbuger i disassembler ?! fakt ze ciezko jest zdekompilowac oprogramowanie napisane w c++ nieoznacza ze niemozna go zlamac ;) jesli ktos umie lamac zabezpieczenia oprogramowania (czyli zna assemblera i umie korzystac debbugerow (cracking)) to nieistotne czy to jest open source czy komercha. a i faktem jest ze open source daje taka mozliwosc ze sam mozesz zmienic sobie kod na leprzy o ile czujesz sie takim "kozakiem" by to zrobic ;)
pozdrawiam

Ja chciałbym poruszyć inną kwestie.

Jak wygląda testowanie aplikacji, które tworzymy. Nie mówię tutaj tylko o aplikacjach webowych. Z moich dotychczasowych, krótkich doświadczeń oraz rozmów ze znajomymi z branży IT widzę problem w tej kwestii. Test Driven Development oraz wszelakie testy jednostkowe, automatyczne testy funkcjonalne itp to mit. Niestety jest to rzadka praktyka w firmach IT, bo liczy się czas...

Przypominam, że testowanie systemów IT szacunkowo trawa 20-30% czasu a systemów krytycznych 70-80%. Zastanawiam się jak się to ma do do aplikacji z których wykradziono dane. Wiadomo, że błędy są oczywiste, jednak czy są one weryfikowane na poziomie rozwoju aplikacji?

Dawid D.:Wiadomo, że błędy są oczywiste, jednak czy są one weryfikowane na
poziomie rozwoju aplikacji?

W tym miejscu mamy właśnie do czynienia z jedną z największych zalet dojrzałych rozwiązań Open Source czyli testy wykonywane przez społeczność użytkowników z całego świata. Liczba testerów w tym przypadku nie jest jedynie ograniczona do wielkości działu danej firmy, a całej społeczności, której skala idzie często w setki tysięcy osób.

Nie przemawia do mnie stwierdzenie, że rozwiązania Open Source nie są bezpieczne ze względu na fakt, że kod jest dostępny dla każdego, nawet potencjalnego włamywacza. Dobry włamywacz to często osoba wybitna z zakresu programowania i zagadnień związanych z bezpieczeństwem sieci i fakt otwartości kodu nie jest dla niej żadnym ułatwieniem.

Dodam jeszcze jedno. Komercyjne produkty są bardzo często oparte o komponenty na licencji Open Source, ale nikt o tym głośno nie mówi, żeby klient przypadkiem się nie dowiedział, że płaci za rozwiązanie, które jest ogólnodostępne. Z punktu widzenia bezpieczeństwa dużo gorszą sytuacją jest kiedy firma komercyjna sama do końca nie wie co znajduje się w kodzie oprogramowania, które dystrybuuje. Niestety z mojego doświadczenia oraz opinii moich klientów wynika, że występuje to bardzo często. Dzieje się tak ze względu na braki w dokumentacji i częste zmiany w kadrach.

Reasumując, stwierdzenie o mniejszym bezpieczeństwie rozwiązań Open Source uważam za kolejny mit (http://sugarcrm.com.pl/open-source-mity-i-fakty/), który nie ma żadnego potwierdzenia w praktyce.

Pozdrawiam,
Marcin

eVolpe Consulting Group
marcin.rozanski@evolpe.pl
http://evolpe.plMarcin Różański edytował(a) ten post dnia 10.05.11 o godzinie 20:19

Dawid D.:
Ja chciałbym poruszyć inną kwestie.

Jak wygląda testowanie aplikacji, które tworzymy. Nie mówię tutaj tylko o aplikacjach webowych. Z moich dotychczasowych, krótkich doświadczeń oraz rozmów ze znajomymi z branży IT widzę problem w tej kwestii. Test Driven Development oraz wszelakie testy jednostkowe, automatyczne testy funkcjonalne itp to mit. Niestety jest to rzadka praktyka w firmach IT, bo liczy się czas...

Przypominam, że testowanie systemów IT szacunkowo trawa 20-30% czasu a systemów krytycznych 70-80%. Zastanawiam się jak się to ma do do aplikacji z których wykradziono dane. Wiadomo, że błędy są oczywiste, jednak czy są one weryfikowane na poziomie rozwoju aplikacji?

Ja po kilku latach pracy w IT zauważyłem coś takiego ze odbiorca bardzo rzadko ma świadomość o czymś takim jak bezpieczeństwo aplikacji, niektórzy mają problem ze zrozumieniem po co backupy itp. Przy wyborze wykonawcy systemu liczy się cena a co za tym idzie tnie się koszty np właśnie na testach - bo na funkcjonalności oprogramować trzeba ale testować to już nie zawsze. Potem jest płacz i zgrzytanie zębów że firma im źle zrobiła itp itd.

Z tego co mi wiadomo, niestety nie mam raportów potwierdzających to stwierdzenie, wprowadzenie Test Driven Developement w dłuższej perspektywie zmniejsza koszty wytworzenia oprogramowania. Fakt, że oprogramowania powstaje wolniej, jednak faza poprawiania błędów jest znacznie krótsza. Problem we wprowadzeniu tej metodyki jest pozorne wydłużenie czasu rozwoju oprogramowania oraz doświadczenie architekta tworzącego szkielet oprogramowania. Chodzi tutaj o stworzenie aplikacji łatwo testowalnej, skalowalnej itp.

Dawid D.:
Z tego co mi wiadomo, niestety nie mam raportów potwierdzających to stwierdzenie, wprowadzenie Test Driven Developement w dłuższej perspektywie zmniejsza koszty wytworzenia oprogramowania. Fakt, że oprogramowania powstaje wolniej, jednak faza poprawiania błędów jest znacznie krótsza. Problem we wprowadzeniu tej metodyki jest pozorne wydłużenie czasu rozwoju oprogramowania oraz doświadczenie architekta tworzącego szkielet oprogramowania. Chodzi tutaj o stworzenie aplikacji łatwo testowalnej, skalowalnej itp.

Wile rzeczy w dłuższej perspektywie zmniejsza koszty ale niestety często liczy się tu i teraz i często utrzymaniem zajmuję się ktoś inny niż wdrożeniem i mniejsze testy to mniejsze koszty wdrożenia co powoduje że więcej kasy zostaje u wdrożeniowców a co potem to już nie ich brożka. Często nie ma też czasu na testy. A w dużej mierze winna jest tu nieświadomość odbiorcy końcowego.

swojego czasu niebezpiecznik prowadził jakieś szkolenia / audyty z tego zakresu.

"Hakerzy idą na wojnę z całym światem", czyli wyczyny grupy anonimowych hakerów LulzSe pokazuje, że luki w aplikacjach internetowych są i cały czas istnieć będą.

Więcej na temat wyczynów grupy hakerów:
http://technologie.gazeta.pl/internet/1,104530,9825094...

Pozdrawiam serdecznie

Jacek Suski
http://lean-soft.com