O bezpieczeństwie "nowych" e-Deklaracji
W wypowiedzi dla portalu Gazeta.pl koledzy z Securitum "na szybko" ocenili bezpieczeństwo serwisu e-Deklaracje. Jest to dobry argument, że słowa "bezpieczeństwo" i "na szybko" nigdy nie powinny występować w jednym zdaniu.
Jeśli chodzi o dostępność strony e-Deklaracje po SSL to częściowa zgoda. Polskie urzędy i firmy zdają się nie rozumieć, że SSL nie służy wyłącznie do ochrony przed podsłuchem, ale przede wszystkim do zagwarantowania, że klient łączy się autentycznym i zaufanym serwerem. Jeśli urząd taki jak Ministerstwo Finansów wystawia jakieś formularze petentom, to dobrze byłoby dopieścić ich maksymalnie pod względem dobrego samopoczucia, na przykład w postaci kłódeczki u dołu ekranu.
Z punktu widzenia analizy ryzyka a nie PR rozwiązanie w e-Deklaracjach jest poprawne, bo dane do bramki jednak idą po SSL. Bardziej uzasadnione byłoby podpisywanie wtyczki do e-Deklaracji (a ściślej tego instalatora EXE). Certyfikat do podpisywania kodu w GoDaddy kosztuje 200 USD rocznie, więc nie róbmy scen...
Średnio trafiony jest zarzut o stosowaniu 40-bitowego DES. Z pewnością jest to sprzeczne z "dobrymi praktykami inżynierskimi" oraz zaleceniami wszystkich możliwych instytucji z NIST na czele. Ale znajmy proporcje - nikt nie będzie łamał 40-bitowego DES (co jest nadal znacznie trudniejsze niż złamanie 128-bitowego RC4 w WEP) tylko po to, żeby podsłuchać cudzą deklarację podatkową. Najpierw ktoś musiałby mieć ku temu powód, a potem jest tysiąc prostszych sposobów (patrz pouczający rysunek z XKCD).
Na pewno brakuje publicznie dostępnej analizy ryzyka. To jest przypadłość wszystkich projektów w polskiej administracji publicznej, nie tylko e-Deklaracji. Urzędnikom wydaje się zapewne, że jeśli nie napiszą w zamówionej za 200 tys. zł ekspertyzie o jakimś zagrożeniu, to nikt o nim nie będzie wiedział (np. że statyczne hasła są podatne na phishing). To wymaga rozwiązania systemowego oraz częstego korzystania z prawa do informacji publicznej, aż się nie nauczą że łatwiej samemu wystawić.
Piszę o tym z dwóch powodów. W naszej administracji publicznej działa obsesyjnie uwarunkowane lobby zwolenników niezwykle silnego, ale nieużywalnego "bezpieczeństwa wszystkiego" . Można dyskutować, czy chodzi o zwykłą obsesję czy o zwykłe pieniądze. Każda taka publikacja staje się pożywką dla lobby, które będzie ten artykuł drukować i używać jako argumentu dla konieczności wprowadzenia trzystopniowego uwierzytelnienia dla wszystkiego (by wszystko było tak bezpieczne, żeby nie było niczego). Nie chodzi o to, żeby nie pisać o dziurach, chodzi o to by nie pisać o nich "na szybko".
Po drugie, dziennikarze mają skłonność do przesadzania, bo z tego mają pieniądze. Kiedy pewna poczytna gazeta o wiarygodności proporcjonalnej do swojej ceny opublikowała tekst pod tytułem "Posłowie chcą zakazać prezerwatyw" to nie zrobiła tego w ramach spisku, tylko dla przyciągnięcia uwagi czyli dla pieniędzy (a chodziło o to, żeby na pudełkach z tabletkami hormonalnymi pisać o skutkach ubocznych). Sam musiałem kiedyś wycofać swoją wypowiedź na etapie autoryzacji, kiedy dziennikarz mój "mało prawdopodobny problem z bezpieczeństwem" chciał przerobić na "katastrofę od której natychmiast umrze mnóstwo emerytów" (moja parafraza). Firma zajmująca się bezpieczeństwem nie powinna występować w takim kontekście.
- Zaloguj się lub zarejestruj by odpowiadać
- Generate PDF file
- Wersja do wydruku
Odpowiedzi
W przypadku osób prywatnych to pół biedy - sam mógłbym pewnie wystawić swoją deklarację publicznie. Nie mam w niej nic do ukrycia :]
Gorzej w przypadku firm - a chyba MF zamierza udostępnić system również firmom.
"(...)tylko po to, żeby podsłuchać cudzą deklarację podatkową."
A powiedzmy, że ktoś zmieni taką deklarację? To będzie dopiero problem, jak przyjdzie do dopłaty powiedzmy 100 tyś zł :/
Nie "przyjdzie do zapłaty" tylko co najwyżej przyjdzie wezwanie do wyjaśnienia, dlaczego podatek nie został zapłacony.
Dokładnie taki sam "atak" można przeprowadzić przy pomocy deklaracji papierowej wysłanej listem poleconym lub złożonym w okienku, bo pani w US ani na poczcie nie weryfikuje dowodu osobistego przy wysyłaniu.
Mimo takiego "braku bezpieczeństwa" nie słyszy się o takich "atakach"...
Paweł - miło, że ktoś z "technicznych" zauważył tą publikację.
W tekście dla czytelników popularnego dziennika raczej nie chodziło o wskazanie konkretnych luk, a przynajmniej nie przede wszystkim. Tutaj wniosek do artykułu formułowany jest w samym wstępie: "To nie są superkrytyczne czy krytyczne luki, ale pokazują, że przy wdrażaniu systemu e-deklaracje nie przemyślano kwestii bezpieczeństwa od A do Z".
To jest robocza hipoteza, dla której umocowania zostały przytoczone pewne dowody. Optymalnie gdyby pojawiły się teraz dyskusje tego typu jak ta. Na forum wyborczej jednak cisza jak makiem zasiał...
Chyba też warto mówić o bezpieczeństwie w ogólnopoczytnej prasie. Tego artykuły nie będą oczywiście mocno techniczne ani nie będą niosły rozsądnej wiedzy dla specjalistów od bezpieczeństwa.
Nie powinny z kolei siać zbędnej paniki, czy po prostu kłamać. Wydaje mi się, że oba te cele zostały w miarę spełnione...
Warto też pamiętać, że tego typu teksty posiadają pewną specyfikę - zarówno jeśli chodzi o treść jak i rygory czasowe w przygotowaniu (o tym trochę dalej).
W temacie ogólnego podsumowania to tyle. A bardziej szczegółowo:
Mowa jest o potencjalnym naruszeniu zasad due care / due dilligence (tj upraszczając: należytej staranności odnośnie bezpieczeństwa przy wdrażaniu / obsłudze systemu).
http://en.wikipedia.org/wiki/Information_security
I może warto się temu dalej przyjrzeć (jestem ciekaw jak cała sprawa się potoczy).
Nawet nie chodzi o konkretne błędy - taki 40 bitowy DES czy RC4. Odpowiednie zabezpieczenie SSLa to jeden z podstawowych kroków hardeningu systemu - być może zgodzisz się też z tezą, że "gdybyśmy badali systemy bankowości elektronicznej, tego typu zabezpieczenia byłyby nie do przyjęcia". Tutaj - może są do przyjęcia - może nie są. Trudno powiedzieć. Na prawdopodobny brak hardeningu wskazuje też dołączenie publikacji o dokładnej wykorzystywanej wersji JBoss-a, mod_ssl-a, czy apache. Jeśli nie wykonano tego typu hardeningnu, to raczej nie robiono tego głębiej.
Przykład: podchodzisz do nowego auta i widzisz, że jest dziura w szybie, wgniecenia na karoserii, po zapaleniu silnika coś lekko stuka. Tego typu usterki widzisz po 15 minutach. Producent zapewnia, że autem jeździ się bardzo bezpiecznie. Czy na podstawie tych niegroźnych, ale widocznych gołym okiem usterek, nie postawiłbyś hipotezy że samochód może ukrywać o wiele poważniejsze "podatności" ?
Co do dwóch opisanych przez Ciebie powodów publikacji tekstu w ipsec:
1. Lobby bezpieczeństwa w administracji publicznej. Szczerze mówiąc to nie widzę tego lobby :/ Tj. moje doświadczenia z branżą mówią co innego (policja, sondy, przemysł).
Bezpieczeństwo? A co to?
Widzę za to problemy przy wyciąganiu kasy i to naprawdę na masową skalę. Czy coś jest potrzebne czy nie - kupujemy, oczywiście jeśli jest ku temu odpowiednia zachęta.
Z innej strony ostatnio widziałem światełko w tunelu - w jednym z przetargów dotyczących audytu bezpieczeństwa był zapis o późniejszej publicznej publikacji - przynajmniej ogólnych - wyników.
2. Skłonność do przesadzania. Tutaj kwestia odpowiedniego wyważenia. Co to znaczy odpowiedniego? Nie wiem :/ Zauważ, że generalnie cały marketing / PR / media to pewna przesada. Ale w ten sposób dociera się do ludzi. Zwraca się im uwagę na pewne kwestie. Trzeba mrugać / świecić / krzyczeć. Inaczej tzw. mainstream Cię nie usłyszy. Osobiście chciałbym żeby było inaczej - przedstawiasz błyskotliwy, merytoryczny, odpowiednio rozbudowany tekst i ludzie to czytają, rozumieją, dyskutują. Sam z takiej dyskusji sporo wynosisz. Ale tak nie jest :-/
Zauważ też, że nawet powiedzmy poważne materiały są bardzo często (zawsze?) okraszane mocną dawką marketingu / PR-u / sensacji / skandalu. Zobacz np. publikacje dotyczące ostatniego "ataku na SSL" prezentowanego w ramach BH USA.
Teoretycznie GW mogło próbować robić z tego skandal - wiadomo - poczytność. Ale nie zrobiło. Wyszedł w sumie tekst który:
a) Raczej na tle głównych newsów słabo przemawia do odbiorców "popularnych" - bo myślą - i co z tego? Nie ma krytyczny błędów, nie można wyciągnąć w prosty sposób danych. Eeeeeee...
b) Trochę słabo przemawia do odbiorców "technicznych" (choć to nie jest dobra grupa docelowa). Mało technikaliów, uproszczenia, "szybki audyt" bez wniknięcia w szczegóły, błeeeeeee...
W dziennikach jest też trochę tak, że niejako jest wymóg robienia niektórych rzeczy "na szybko" - albo publikujemy "newsa". Albo news przestaje być newsem. Można oczywiście odpuścić. Czy warto w takich sytuacjach odpuszczać - nie wiem :-) Nasuwa mi się tylko analogia: w TV proszą Cię o komentarz odnośnie bieżącej sytuacji w Czeczenii. A tu odpowiedź: no wie Pan - potrzeba co najmniej 2 tygodni na dokładniejszą, profesjonalną analizę sytuacji, wyjazdy, badania, itp. No to może coś o najnowszej ustawie o emeryturach? Wie Pan, to nie takie proste, trzeba sprawdzić, zastanowić się, mamy jeszcze za mało danych. Można i tak. Znowu - która droga jest lepsza? Nie wiem.
Na koniec trochę przykładów z branży:
Widziałem publikację o błędach SQL injection w portalach polskich banków - wskazanych z 15 banków (bez podawania konkretnych nazw). Poważne zagrożenie? No powiedzmy. Co ciekawe nikt spośród poczytnych nie chciał tego opublikować. Za bardzo techniczne, za bardzo zadzierające z finansówką. No otwarta wojna.
Bardzo duży bank w Polsce. Po informacji przesłanej do Banku - na swojej stronie posiadają SQLi - wraz z określeniem charakterystyki - wskazaniem zewnętrznych
linków, itp. odpisują: certyfikat bezpieczeństwa na stronie banku jest rzeczywiście nieważny, jednak w bankowości elektronicznej jest OK.
A co ma piernik do wiatraka?!?
Ten sam bank w wskazaniu skryptu cgi umożliwiającego zdalne wykonanie polecen w OS-ie: publiczny link do skryptu został usunięty - choć sam skrypt i jego odwołania w cache google zostały...
Na razie nie chcę też bardzo wchodzić w szczegóły wskazanych przez nas błędów - z drobnych uwag można i wynegocjować 40 bitowy RC4 (nikt w tekście na wyborczej nie mówił, że można użyć tylko 40 bitowego DES. Hint dla openssl: -cipher EXPORT40+RC4).
Jeszcze kilka uwag w temacie szacowania ryzyka. Tutaj podejrzewam, że w ogóle takowe było robione dosyć ogólnie - bez uwzględnienia całości systemu. W takiej analizie powinny być pewnie też określona wartość tych danych i odpowiednio (cenowo) dobrane środki ochrony. Ciekaw jestem wyceny wartości tych danych.
Można oczywiście zaakceptować ryzyko lub się ubezpieczyć. Ale świadomie. Czy tutaj zostało to wykonane świadomie?
W przypadku SSL-a koszt odpowiedniej konfiguracji jest niemal zerowy (jeśli masz odpowiedniego admina - a chyba takim system powinien się zajmować odpowiedni admin). No chyba, że odpowiednie zabezpieczenie warstwy protokołu SSL nie zostało wskazane jako jeden ze środków ochrony przed zagrożeniem wypływu poufnych danych. Ew. zostało wskazane, ale zostało źle wdrożone. Ale co z takich zabezpieczeń? Firewall też może stać, a że nie skonfigurowany... ;-) Odpowiedzi na te pytania być może udzieli Zamawiający ;-)
Na koniec tej mojej tyrady, kilka pytań:
1. Czy mamy jakieś przykłady wyważonych tekstów o bezpieczeństwie IT publikowanych w poczytnych polskich dziennikach?
2. Czy jest sens takie publikacje tworzyć?
3. W jaki sposób je przygotowywać?
4. Czy w Polsce potrzebna jest świadomość o bezpieczeństwie IT?
5. Czy jest szansa żeby przyszła ona w przeciągu kilku lat?
6. Czy o wygranych w przetargach / konkursach ofert - na systemy IT - decydowało będzie kiedyś ich bezpieczeństwo?
7. Czy w tworzonych na potrzeby PL rynku systemach IT rozważa się na poważnie bezpieczeństwo (począwszy od formułowania wymagań dla systemów)?
8. Czy temat podejścia do bezpieczeństwa IT jest jakościowo różny w firmach prywatnych vs organizacje publiczne?
PS
Gratulacje dla wszystkich, którzy dotarli aż tutaj ;-)
pozdrawiam serdecznie
ms