Krzysztof Katowicz-Kowalewski

@gps65 heh, w tym momencie to już jestem całkowicie pewny że robisz to dla zasięgów ;) cóż, gdyby komuś chciało się wejść w linka to znajdzie tam więcej merytorycznego contentu który nie trafił w poglądy autora. Kończę, miłego prowadzenia dalszej rozmowy z innymi których ten temat kręci

Ten poniższy komentarz idealnie oddaje mentalność branży IT. Król jest nagi, więc dzieci go pytają dlaczego, a król odpowiada, że to tajemnica, ale obok przechodzi komputerowy ekspert, więc jego pytają. A on dzieciom odpowiada: jak dacie po sto lizaków, to wam odpowiem.

@gps65 @BartekSzyma Budując realne systemy musisz wybrać komu ufasz - nie da się praktycznie nie ufać nikomu.

@gps65 @BartekSzyma głównie dlatego, że cała Europa jest narażona na supply-chain risk ze strony US jeśli mielibyśmy zakładać wrogie działania z ich strony, i wykorzystanie vendora do WAFa nie ma dużego znaczenia. To dlatego Chiny budują całe systemy operacyjne od zera albo w oparciu o open-source.

Apel do ekspertów cyberbezpieczeństwa i architektury systemów informatycznych w sprawie #KSeF #gps65, #JSON, #API, #WAF, #Imperva, #IT Sprawa, z którą się do Was zwracam, dotyczy wyłącznie warstwy technicznej systemu KSeF i zakresu danych widocznych w odpowiedziach jego interfejsów. By to zbadać, przeprowadziłem proste audyty, które są łatwe do powtórzenia. Jeżeli gdziekolwiek w mojej analizie jest błąd, proszę o wskazanie go. Jeżeli błędu nie ma, również proszę, by to zostało jasno zakomunikowane. Dla osób spoza branży potrzebne jest krótkie wyjaśnienie pojęć. API to techniczny interfejs komunikacyjny, przez który program księgowy komunikuje się z systemem KSeF przekazując mu dane i odbierając je. JSON to standardowy, tekstowy format zapisu informacji używany w nowoczesnych systemach informatycznych do przekazywania ustrukturyzowanych danych. WAF to bramka bezpieczeństwa stojąca przed właściwym systemem, której zadaniem jest filtrowanie ruchu sieciowego oraz ochrona infrastruktury przed cyberatakami, złośliwym oprogramowaniem i innymi próbami naruszenia bezpieczeństwa, zanim ruch trafi do systemów państwowych. W standardowej komunikacji z API KSeF, w jawnej odpowiedzi JSON, pojawiają się dane o charakterze biznesowym. Widoczny jest identyfikator podatkowy NIP sprzedawcy i nabywcy, pełne nazwy podmiotów, kwoty transakcji netto, VAT i brutto, waluta, numer faktury, daty operacyjne oraz typ dokumentu. Nie jest to interpretacja ani hipoteza. Jest to zwykła obserwacja odpowiedzi systemu w scenariuszu przewidzianym przez jego projektantów, zgodna zarówno z dokumentacją API KSeF 2.0, jak i z prostymi audytami technicznymi możliwymi do samodzielnego powtórzenia. Dane te są widoczne dla operatora bramki WAF w systemie KSeF, którą realizuje firma Imperva. Nie wiadomo, czy dane te są logowane lub w inny sposób utrwalane, natomiast z technicznego punktu widzenia istnieje możliwość ich przetwarzania. Jedyną potencjalną barierą ograniczającą takie działania mogą być zapisy umowne, których treść nie jest publicznie znana. Ministerstwo Finansów nie publikuje tej umowy ani nie informuje oficjalnie o wykorzystaniu konkretnego operatora WAF. Stawiam dwa pytania o charakterze wyłącznie eksperckim: 1⃣. Czy potwierdzacie, że operator bramki WAF widzi jawne, niezaszyfrowane metadane opisane wyżej, czyli NIP sprzedawcy i nabywcy, nazwy podmiotów, kwoty transakcji netto, VAT i brutto, waluta, numer faktury, daty operacyjne oraz typ dokumentu? 2⃣. Jeśli tak, to czy obecność opisanych danych biznesowych w jawnej warstwie komunikacyjnej systemu państwowego, widocznych dla operatora infrastruktury pośredniczącej, ma z punktu widzenia cyberbezpieczeństwa i ochrony tajemnicy handlowej znaczenie architektoniczne i ryzyko systemowe? Te pytania wymagają odpowiedzi specjalistów, nie publicystów. Dlatego zwracam się do osób zajmujących się bezpieczeństwem IT, projektowaniem infrastruktury państwowej i analizą protokołów komunikacyjnych. Proszę o samodzielną weryfikację. Proszę o wskazanie błędu metodologicznego, jeżeli istnieje. Proszę o potwierdzenie wyniku, jeżeli jest poprawny. Każda z tych odpowiedzi będzie cenna, pod warunkiem że będzie miała charakter techniczny i możliwy do sprawdzenia. Pełna dokumentacja moich testów i audytów technicznych znajduje się poniżej i stanowi materiał źródłowy przeznaczony do niezależnej oceny. Ale nie ma konieczności korzystania z nich. Można samodzielnie przeprowadzić swoje audyty i odpowiedzieć na moje dwa pytania. Bardzo proszę o pomoc. Grzegorz GPS Świderski

@gps65 @BartekSzyma wybacz Grzesiek ale nie będę robił ci zasięgów; oceny ryzyka i analiza audytów to usługi komercyjne - tu odpowiadam dla fun’u po godzinach pracy

@varseand @BartekSzyma To pisz pod moimi licznymi notkami na blogach. Szukaj po słowach: GPS65 KSeF.

@BartekSzyma @gps65 taka dyskusja na X’ie byłaby całkiem ciekawa choć nie wiem czy merytoryczna

Z całym szacunkiem, ale jeżeli ministerstwo samodzielnie akceptuje tak wysokie ryzyko to coś jest mocno nie tak. W przypadku tego typu systemów, powinna się odbyć szeroka dyskusja z uwzględnieniem potencjalnych korzyści vs potencjalne problemy? Pytanie, czy ryzyko w ogóle usprawiedliwia wprowadzenie systemu, który potencjalnie zagraża całej gospodarce.

@gps65 Nie wiem, daleko mi do polityki. Mogę jedynie zgadywać, że jeśli była to intencjonalna decyzja to mogła wynikać z akceptacji ryzyka przez to, że i nie da się go całkowicie wyeliminować i dlatego lepiej przeznaczyć zasoby na inny cel. Dosyć częsta praktyka w zarządzaniu ryzykiem.

@varseand To dlaczego Polska jako jedyna na świecie oddała na tacy dane o całej naszej gospodarce zagranicznej grupie zajmującej się wywiadem? A jednocześnie władze boją się danych zbieranych przez chińskie samochody! Głupie, nie?

@gps65 Polecam też ciekawy temat jak działają CA, które technicznie są w stanie podpisać certyfikaty dowolnych domen *.pl. Biorąc to pod uwagę kwestia używania vendora z produktem o dobrej renomie, nawet w modelu SaaS, nie brzmi tak złowrogo :)

@gps65 Mimo wszystko zmartwię Cię jednak chyba bo jeśli uwzględnimy duże firmy amerykańskie w naszym modelu zagrożeń to nie potrzebują one KSeFu, wystarczy im monopol na systemy mobilne i desktopowe żeby mieć techniczne środki na dostanie się do większości rządowych danych.

@gps65 Pierwszy wniosek “połączenie TLS kończy się na infrastrukturze Imperva” jest przedwczesny. Może być jak piszesz (to źle), albo może by “połączenie TLS kończy się na infrastrukturze KSeF z zainstalowanym produktem Imperva” (to lepiej).

@varseand OK, to wskaż, proszę, błędy w moim audycie: informacje-lokalne.pl/audyt-technicz…

@gps65 Nie mam zbyt dużo czasu tego analizować, ale jedna rzecz która rzuciła mi się w oczy to AWS który jest w dużej mierze wykorzystywany przez rząd USA w ramach AWS GovCloud. Warto tu rozróżnić ryzyko supply-chain i inne (bezpieczeństwo produktu, dojrzałość procesów, etc.)

@varseand To dlaczego wszystkim innym krajom na świecie się udało, tylko Polsce nie?x.com/gps65/status/2…

@gps65 1) niekoniecznie, i to starałem się przekazać wyżej

@varseand Prosiłem o odpowiedź na konkretne pytania. Twój komentarz jest nie na temat. To, że Imperva obsługuje WAF, jest pewne, więc o to nie pytam.

@gps65 Prosiłeś o opinię osoby pracujące nad bezpieczeństwem, wyraziłem swoją. Nie do końca rozumiem pytanie. Reszta w pozostałych odpowiedziach przez limit znaków.

@varseand No i co z tego?

@gps65 Technicznie masz rację, że dostawca oprogramowania może umieścić w nim luki albo wydobywać przechodzące przez nie informacje ale to samo można powiedzieć o Microsoftcie i Windowsach na których pracuje administracja.

@gps65 Do potwierdzenia czy zostały tutaj wykorzystane. Jeśli tak, nie brzmi to tak źle bo nie uda się wyeliminować ryzyka łańcucha dostaw (supply-chain risk) z modelu zagrożeń całkowicie.