Zespół zadaniowy ds. ochrony portali rządowych opublikował wytyczne. Trudno stwierdzić, że to najlepsze rekomendacje, jakie można było przy okazji zaistniałych ataków wypracować dokument pryzypomina o elementarzu bezpieczeństwa IT. To ważne, ale chyba nie wystarczające. Zagadką pozostaje też, kto de facto jest autorem tego dokumentu, gdyż nie jest on podpisany. Szkoda, bo to – nie dość, że dobra praktyka – mogłoby wprowadzić trochę porządku w rozpoznaniu struktury odpowiedzialności za zapewnienie bezpieczeństwa teleinformatycznego w domenie gov.pl.
Jako niezbędne wskazane jest w nim ustanowienie stałych kontaktów – jak rozumiem, przez administratorów w domenie gov.pl – z Rządowym Zespołem Reagowania na Incydenty Komputerowe CERT.GOV.PL. Otóż stałe kontakty z tym zespołem istnieją od dawna. Zespół zainstalował w sieciach podmiotów administracji państwowej w ciągu kilku ostatnich lat kilkadziesiąt sond systemu ARAKIS-GOV. Nie dałoby się tego zrobić bez ustanowienia kontaktów z opiekunami tych systemów. Pytanie brzmi raczej: Jak wyglądają te kontakty i czy rekomendacja nie powinna wskazywać na sposoby ich poprawy?
Pomysły na filtrowanie ruchu sprowadzające się do kontroli aktywności internautów to grube nieporozumienie. To są kwestie dotyczące prawa do prywatności. Propozycja z wytycznych stanowi oczywisty atak na te prawa! Z pewnością skrytykują to organizacje pozarządowe. Zrobiła to już np. Fundacja Panoptykon. W warstwie technicznej też nie wygląda to najlepiej. Jeśli ktoś założył, że zebrane naprędce pomysły co do eliminacji takiego ruchu coś tu pomogą, to się grubo myli. Ataki, jakie wystąpiły, można przeprowadzić bez „ruchu anonimizowanego” i część z nich takimi właśnie była. Dodatkowo „wymuszenie ciągłej aktualizacji tych mechanizmów” to w praktyce apel o ciągły projekt badawczo-rozwojowy. Czy ktoś sobie z tego zdaje sprawę?
Apelowanie zaś o wprowadzenie możliwości „całkowitego filtrowania ruchu dotyczącego określonych typów pakietów lub całych protokołów” jest raczej niepotrzebne. Trudno sobie wyobrazić, aby w domenie gov.pl nie było takiej możliwości, to jedna z podstawowych funkcji zarządzania infrastrukturą dołączenia do internetu. Co gorsza, filtrowanie tego ruchu na urządzeniach znajdujących się bezpośrednio w infrastrukturze atakowanych nie spowoduje uniknięcia problemów, jakich doświadczyły serwery rządowe. Może być raczej powodem kolejnych kłopotów administratorów, jeśli urządzenia te przestaną działać w wyniku przeciążenia.
Pomysł przerzucenia odpowiedzialności za zapewnienie ciągłości działania na firmy hostujące i operatorów to sprytny zabieg, ale raczej z dziedziny zamiatania pod dywan. I, niestety, nic nie da. W rzeczywistości ataki nie znikną, bo większość hostujących firm sobie z nimi nie poradzi. Po prostu nie specjalizują się w tym. Chyba lepiej jednak poważnie porozmawiać z operatorami telekomunikacyjnymi, np. w ramach istniejącego Abuse-Forum, co można w takiej sytuacji zrobić. Chwilowe zwiększenie przepustowości, wykorzystanie mechanizmu „blackholingu”, dołączanie się do więcej niż jednego operatora czy skorzystanie z usług przetwarzania w chmurze to tylko niektóre z pomysłów, jakie mogłyby pomóc. Zdecydowanie brakuje ich w zestawie wytycznych. To naprawdę dziwne w sytuacji, kiedy właśnie problem blokady serwisów był najbardziej dokuczliwy i najbardziej kojarzony z atakami.
Kolejnym przypadkom mają zapobiec dalsze rekomendacje. Pomysł z automatycznym – lub na żądanie – przełączeniem wersji witryn jest słuszny. Zachęcałbym jednak do unikania przełączania na informację „przerwa techniczna”. Warto doprowadzić do tego, żeby serwis „statyczny” był zawsze dostępny w takiej konfiguracji, która maksymalnie redukuje możliwość skutecznego ataku. Dobrym pomysłem jest także wprowadzenie usługi rozkładającej ruch.Mechanizmy dotyczące kontroli integralności również są warte zachodu. To elementarz bezpieczeństwa w przypadku ochrony krytycznych systemów i należy tylko żałować, że taka rekomendacja musi być publikowana. Co prawda, zmiana integralności systemów rządowych prawie zawsze jest szybko wykrywana przez społeczność internetową, niemniej warto się o tym dowiedzieć ze swoich systemów kontroli, a nie z internetowych serwisów informacyjnych lub forów hakerskich.
Wszystkie zalecenia dotyczące ochrony poczty elektronicznej są tak oczywiste, że aż dziwi, iż wprowadza się je dopiero teraz. Dodam tylko, że dziś podstawowym mechanizmem pracy stał się również dostęp do poczty poprzez urządzenia mobilne. O jego bezpieczeństwo przy tej okazji też koniecznie trzeba zadbać. Pozostaje jednak pytanie, jak to zrobić i czy się uda? Zalecenia te, w odróżnieniu od poprzednich, dotyczą w praktyce niemal wszystkich pracowników domeny gov.pl. Łatwo napisać, trudniej zrobić. Jeśli ma się udać, wiąże się to z programem szkoleniowym na dużą skalę. Wbrew pozorom, przekonanie użytkowników sieci do bezpiecznych zachowań nie jest zadaniem łatwym. Wie o tym dobrze rząd australijski, który w kosztach implementacji zabezpieczeń szacuje skłonność użytkowników do akceptacji rozwiązań bezpieczeństwa.
Wdrażanie zaleceń i wytycznych publikowanych przez CERT.GOV.PL to pomysł bardzo dobry. Ale kolejny raz należy uświadomić sobie, że przygotowanie takich publikacji nie jest zadaniem trywialnym. Wiąże się z poważnym projektem polegającym na przygotowaniu zestawu konfiguracji „startowych” i tych, potrzebnych do stałego utrzymania bezpieczeństwa systemu. To naprawdę dużo pracy. Stwierdzeniem o istnieniu rekomendacji sprawy nie załatwimy, bo one powinny dopiero powstać! Warto się zastanowić, czy rekomendacja MAiC w tym zakresie nie powinna brzmieć: „należy bezwzględnie stworzyć zestaw zaleceń i wytycznych z zakresu bezpieczeństwa IT dla administratorów systemów w domenie gov.pl”.
No i wreszcie sprawa reagowania na incydenty. Zgłaszanie incydentów do zespołu CERT.GOV.PL jest jak najbardziej słuszne. Tylko czy to na pewno będzie działać? Pytanie należy postawić wprost – Jaka jest skłonność pracowników administracji państwowej do zgłaszania incydentów to zespołu, który funkcjonuje w strukturach ABW? Obawiam się, że niezbyt duża. Te incydenty w dużej mierze ujawniają słabości techniczne i proceduralne w instytucjach, w których doszło do ataku. Trudno uwierzyć w to, że akurat chętnie będzie to zgłaszane do ABW, w pewien sposób donosząc na siebie.
ABW odgrywa bardzo istotną rolę w zapewnieniu bezpieczeństwa Państwa, ale to nie znaczy że jest predysponowane do realizacji wszystkich zdań, które powinny towarzyszyć rządowemu zespołowi typu CERT. Zadania, które związane są ze swobodną wymianą informacji i sprawną koordynacją – często opartą o działania podejmowane ad hoc – wymagają dużej elastyczności. Bazują one również na wypracowanym modelu wzajemnego zaufania. Zespół pracujący w strukturach, które muszą działać i kontaktować się ze światem zewnętrznym wg bardzo ścisłych procedur, ma bardzo utrudnione zadanie w tej materii. To są czasami zadania niewykonalne dla tak sformalizowanej i specyficznej instytucji. Do dziś na stronach CERT-u rządowego nie można znaleźć informacj o tych atakach. A taka informacja z pewnością znaleźć się powinna. Znam dobrze osoby pracujące w zespole CERT.GOV.PL i nie mam wątpliwości co do ich fachowości i chęci do współpracy, ale wiem dobrze, że to za mało. Konieczność formalnego i ścisłego działania oraz współpraca z tymi, którzy z natury rzeczy podchodzą do takiej współpracy w sposób bardzo formalny i ostrożny, nie sprzyjają możliwości skutecznej jej realizacji niektórych z zadań CERT-owych.
Ulokowanie rządowego zespołu CERT w strukturach służb specjalnych jest unikatowe co najmniej w skali europejskiej. Znany mi jest tylko jeden podobny przypadek – Norwegia, ale tam to działanie wygląda zupełnie inaczej. Inne doświadczenia, inne warunki działania, inna kultura organizacyjna, budżetowa i polityczna, a przedstawiciele tego zespołu są otwarci na współpracę ze środowiskiem CERT-ów od lat uczestnicząc w międzynarodowych spotkaniach i dzieląc się wiedzą i doświadczeniami. Protoplaści umiejscowienia rządowego zespołu CERT w strukturach ABW postawi przed tym zespołem zadanie bardzo trudne do wykonania, jeśli w ogóle możliwe. Warto nad tą decyzją pochylić się raz jeszcze, a doświadczenia z ataków związanych z ACTA są doskonałym materiałem pomagającym w tej decyzji. Weźmy przykład z państw takich jak Estonia czy Korea Południowa, które po podobnych problemach w sieci wypracowały modelowe rozwiązania, często przywoływane i chwalone przez innych. Dlaczego nie mogłoby być tak samo w Polsce?
