WebTotem zbadał bezpieczeństwo stron 33 polskich banków. Wszystkie przebadane banki mają pewne - choćby błache - problemy z bezpieczeństwem. Przedstawiamy pełny raport “Ocena Bezpieczeństwa Teleinformatycznego Banków w Polsce”

1. OCENARYZYKA
TELEINFORMATYCZNEGO
BANKÓWWPOLSCE
©LLC WebTotem 2017-2020, Wszystkie prawa zastrzeżone

2. 02/34
20
21-23
24
25
26
g. Bezpieczeństwo sieciowe (otwarte porty)
h. Bezpieczeństwo poczty elektronicznej
i. Stan obecny
j. Zgodność z RODO
k. Zgodność z security.txt
a. Skład oprogramowania
b. Wydajność strony
c. Reputacja IP/Domeny
d. Ocena Nagłówków Bezpieczeństwa HTTP i Polityki
Bezpieczeństwa Treści
e. Szyfrowanie ruchu
f. Wyciek informacji:
11
12
13
14-15
16-18
19
11-26• Główne wyniki
27
28
29-30
31-32
33
34
• Wnioski
• Podsumowanie
• Studium przypadków
• O firmie
• Uczestnicy
• Kontakt
• Glosariusz
• Wstęp
• Cel badania
• Badane podmioty
• Krótki opis wyników
• Metodologia oceny
03
04
05
06
07-09
10
Spis Treści

3. 03/34
Atak
próba zniszczenia, upublicznienia,
modyfikacji, wyłączenia, kradzieży
czy nieautoryzowanego dostępu do
lub użycia zasobu
Ryzyko
efekt niepewności na cele biznesowe
Zagrożenie
potencjalna przyczyna niechcianego
zdarzenia, które może wywołać
szkodę w systemie czy organizacji
Bezpieczeństwo
informacji
utrzymywanie poufności,
integralności i dostępności informacji
Podatność
słaby punkt zasobu czy elementu
sterowania, który może być
wykorzystany przez jedno lub więcej
zagrożeń
Glosariusz OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

4. 04/34
Audyt wykonano
w pierwszej
połowie czerwca
2020 r.
wprowadzanych przez użytkownika, a zatem
działania podjęte w ramach pracy nie obejmują
jawnych ataków na dany zasób.
Praca zawiera analizę sposobów na
przygotowanie ustawień zalecanych dla serwerów
pracujących w sieci i elementów z nimi
związanych
Mamy nadzieję, że wyniki tego badania ułatwią
działom bezpieczeństwa informacji w bankach
identyfikację podatności, które mogą potencjalnie
stać się dostępne dla dzisiejszych
cyber-przestępców.
Oczekujemy również, że niniejsza analiza
przyczyni się do weryfikacji zasobów sieciowych
tych banków przez ich służby wewnętrzne, a w
przyszłości, pomoże podnieść poziom ochrony
poprzez zastosowanie najlepszych
międzynarodowych praktyk.
Obecnie, trzy z pięciu nowoczesnych banków
europejskich znajdują się w Polsce.
Według Deloitte, polski rynek bankowości jest
liderem w dojrzałości cyfrowej w Internecie i na
kanałach mobilnych. W sprawozdaniu
zatytułowanym „CE Banking Outlook Winning in
the Digital Arms Race”, wyróżniono trzy banki z
Polski spośród czołówki pięciu
najnowocześniejszych banków w Europie
Środkowej.
Ponadto, Polacy przodują w Europie pod
względem zakupów internetowych, płatności
bezdotykowych i płatności na odległość.
Głównym celem obecnego badania było określenie
jak polskie banki zapewniają bezpieczeństwo
swoich zasobów sieciowych. Jako punkt
odniesienia wybrano najlepsze międzynarodowe
praktyki i zalecenia uznanych twórców
oprogramowania i społeczności
międzynarodowych.
Badanie wykonano za pomocą produktu
WebTotemAI.
Podczas badania, specjaliści z WebTotem AI nie
ingerowali w działanie zasobów internetowych
banku. W celu wykonania sprawdzeń, wystarczyło
wysłać „lekkie” zapytania HTTP i DNS, i
przeanalizować odpowiedzi pochodzące od
serwera. W ten sposób, wszystkie dane zebrano,
tak jak mógłby to zrobić zwykły użytkownik
odwiedzający zasób.
Obecna praca nie odnosi się do ataków i
podatności, przeciw którym ochrona jest
realizowana na podstawie filtrowania danych
Wstęp OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

5. 05/34
Podczas naszego badania próbowaliśmy
określić, jakie potencjalne wektory ataku mogą
być wykorzystywane przez hakerów. Atakujący
może łatwo stworzyć listę kontrolną ustawień
bezpieczeństwa, taką jak nasza, aby budować
dalsze wektory ataku na bank i jego klientów.
Cel badania
Warto podkreślić, że wszystkie informacje przez nas
analizowane są publicznie dostępne, a praca z nimi nie
wymaga specjalnych zdolności czy narzędzi, które nie
byłyby dostępne dla zwykłego użytkownika. Innymi
słowy, chcieliśmy pokazać, że każdy zainteresowany
użytkownik z umiejętnościami technicznymi może dojść
do podobnych wyników.
Głównym celem badania była ocena poziomu bezpieczeństwa publicznie dostępnych zasobów bankowości
(mowa tu o oficjalnej stronie banku), zgodnie z najlepszymi praktykami (takimi jak PCI DSS, GDPR, OWASP
Top-10, OWASP Application Security Verification Standard). Wybraliśmy kilka punktów kontrolnych, które
można sprawdzić bez ingerencji w pracę danego zasobu sieciowego, co wyklucza jakiekolwiek szkody
natury technicznej.
OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

6. 06/34
Weryfikację przeprowadzono dla oficjalnej
strony każdego z banków. Ogółem
sprawdzono 33 strony.
o Haitong Bank, S.A., Warsaw Branch
o NOBLE Bank SA
o Volkswagen Bank Polska
o Societe Generale
o Inteligo
o Nordea Bank Polska
o Skandinaviska Enskilda Banken AB (SA) (SEB)
o Idea Bank Spółka Akcyjna
o FCE Bank Polska (former Ford Bank)
o UBS a.g.
o HSBC Bank Polska
o Bank Handlowy w Warszawie SA (part of Citigroup)
o Bank BPH
o Bank DnB NORD Polska;
o Mazowiecki Bank Regionalny
*Banki wybrano ze względu na to, że ich serwery są
fizycznie położone w Polsce.
o PKO Bank Polski
o mBank
o Alior Bank
o ING Bank Śląski SA
o BNP Paribas Bank Polska
o Bank Millennium SA
o GETIN Bank SA
o Bank Gospodarstwa Krajowego
o Danske Bank Polska
o Mercedes-Benz Bank Polska SA
o Toyota Bank Polska
o Bank Spółdzielczy w Brodnicy
o Bank Ochrony Srodowiska S.A.
o Credit Agricole (former Lukas Bank)
o Bank Polskiej Spóldzielczosci
o Santander Consumer Bank SA (former CC-Bank)
o Bank Pocztowy
o Pekao Bank Hipoteczny
Dla celów badania,
wybraliśmy następujące
polskie banki
Badane podmioty OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

7. 07/34
45% banków podlega
ryzyku wykorzystania
podatności sieciowych
45%
76% banków ma problemy z
zapewnieniem ochrony
danych osobowych klientów
76%
Wycieki informacji
wykryto w 61%
banków
61%
Strona 1 banku ma
negatywną reputację
domeny
1
Średni wskaźnik
bezpieczeństwa stron
bankowych wynosi 61%
61%
Sprawdzono 33
polskie banki
33
100% banków nie ma
zgodności z normą
Security.txt
100%
Znaleziono ponad
2500 wycieków
informacji w jednym z
banków
2500
18% banków nie
przeszło weryfikacji
ustawień SSL/TLS
18%
21% domen ma niską
prędkość ładowania
stron
21%
Średni wskaźnik
Bezpieczeństwa Poczty
Elektronicznej wynosi 80%
80%
12% banków ma otwarte porty
12%
Znaleziono ponad 4500
wycieków informacji
4500
Tylko 9% domen ma wysoką
ocenę bezpieczeństwa w
odniesieniu do nagłówków
HTTP i CSP
9%
Krótkiopiswyników OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

8. 08/34
Końcowa ocena bezpieczeństwa banków w Polsce
Krótki opis wyników OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE
83, 7
Strona banku Nazwa banku Wskaźnik bezpieczeństwa,% *Miejsce #
vwbank.pl1 Volkswagen Bank Polska 90, 8
hsbc.pl2 HSBC Bank Polska 88, 7
aliorbank.pl3 Alior Bank
4 83, 6
5 78, 6
6 78, 5
7 76, 6
8 73, 5
9 71, 5
10 68, 8
A1
B5
11 68, 6
A2
B6
12 68, 1
A3
B7
13 66, 5
A4
B8
14 66, 0
B1
B9
15 64, 7
B2
B10
16 64, 5
B3
B11
17 61, 7
B4
B12
B13
B1418 58, 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-

9. 09/34
W tabeli, począwszy od 4-stej pozycji, nazwy banków
są ukryte przez wzgląd na zachowanie prywatności.
* Im niższy wskaźnik, tym gorszy stan bezpieczeństwa sieciowego banku.
Krótki opis wyników OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE
Strona banku Nazwa banku Wskaźnik bezpieczeństwa,% *Miejsce ##
B19
B20
B21
B22
B15
B23
B16
C1
B17
C2
B18
C3
C4
C5
C6
19 - 58, 5
20 - 56, 5
21 - 54, 5
22 - 53, 5
23 - 53, 3
24 - 53, 0
25 - 51, 5
26 - 49, 5
27 - 49, 2
28 - 48, 6
29 - 43, 8
30 - 43, 5
31 - 38, 6
32 - 38, 5
33 - 33,7
Końcowa ocena bezpieczeństwa banków w Polsce

10. 10/34
IP/Domain reputation
Traffic encryption
Information leak
Open ports
Security. txt
Email security
Software composition
Website performance
HTTP Security Headers and
Content Security Policy Scoring
10%
15%
20%
10%
10%
15%
10%
5%
5%10% 15%
10%
15%
10%
10%
20%5%
5%
Stopień krytyczności kryteriów dla wyniku końcowego oceny
bezpieczeństwa zasobów sieciowych
Ocena poniżej 20С-
Ocena w zakresie 20 - 34С
Ocena w zakresie 35 - 49С+
Ocena w zakresie 50 - 59B-
Ocena w zakresie 60 - 69B
Ocena w zakresie 70 - 79B+
Ocena w zakresie 80 - 89A-
Ocena w zakresie 90 - 99A
Ocena wynosi 100A+
• Ocena zasobu sieciowego skonfigurowanego perfekcyjnie pod względem bezpieczeństwa wynosi
100%.
• Punkty są odejmowane za każdą konfigurację strony czy serwera sieciowego, która nie zapewnia
zabezpieczenia, jest niekompletna lub niepewna.
• Ocena podana jako wartość procentowa charakteryzuje liczbę niewykrytych lub odkrytych błędów
związanych z bezpieczeństwem.
Metodologia oceny OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

11. 11/34
używanie przestarzałej wersji oprogramowania, prawdopodobnie już nie obsługiwanej
przez dewelopera. CMS (ang. Content Management Software - oprogramowanie do zarządzania
treściami) lub jego składowe nie są zaktualizowane.
Istnieje wysokie prawdopodobieństwo, że jest sposób który pozwala hakerom wykorzystać
podatności starszych wersji oprogramowania.
Bezprawny dostęp do danych.
Podatność:
Ryzyko:
Negatywne konsekwencje:
Przeszedł
Nie
powiodło
się
1815
Spośród 33 domen, jedynie 18 domen spełnia to kryterium na liście kontrolnej cyber-bezpieczeństwa.
Skład oprogramowania
Ten punkt na liście kontrolnej przedstawia wyniki, które mogą opisywać ryzyko wykorzystania podatności sieciowych,
takich jak Zastrzyk SQL (ang. SQL Injection), uruchamianie skryptów między stronami (ang. Cross Site Scripting),
niedziałające uwierzytelnianie i zarządzanie sesją (ang. Broken Authentication and Session Management),
niezabezpieczone bezpośrednie referencje do obiektów (ang. Insecure Direct Object References), fałszowanie zapytań
między stronami (ang. Cross Site Request Forgery), niepoprawna konfiguracja systemu bezpieczeństwa (ang. Security
Misconfiguration), niezabezpieczone magazynowanie kryptograficzne (ang. Insecure Cryptographic Storage), brak
ograniczenia dostępu do URL (ang. Failure to Restrict URL Access), niedostateczna ochrona warstwy transportowej
(ang. Insufficient Transport Layer Protection), nie-zwalidowane przekierowania i przekazania (ang. Unvalidated
Redirects and Forwards). Więcej informacji można znaleźć na stronie https://www.owasp.org/.
Główne wyniki OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

12. 12/34
Niska prędkość ładowania strony.
Niska wydajność pozwoli atakującym na przeciążenie zasobu sieciowego za pomocą
wybranych zapytań;
niedostępność zasobu sieciowego dla użytkowników.
Podatność:
Ryzyko:
Negatywne konsekwencje:
0-49%
50-79%
80-100%
Wysoka prędkość Średnia prędkość Niska prędkość
33%
46%
21%
Wyniki badania wskazują na to, że 33% domen ma wysoką prędkość
ściągania, 44% domen - średnią, a 21% - niską.
Wydajność strony
Prędkości ściągania oszacowano na podstawie metryk FCP i FID, uzyskanych poprzez symulację
ładowania strony. Przeprowadza się testy najlepszych praktyk wydajnościowych, aby zbadać
odporność strony na obciążenie ruchem.
Główne wyniki OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

13. 13/34
obecność domeny na „czarnej liście”;
Jeśli zasób sieciowy figuruje na „czarnej liście” jednej z baz danych o reputacji,
przeglądarki internetowe odwiedzających mogą blokować zasób sieciowy, a taki zasób może
nawet zniknąć z wyników wyszukiwania w przeglądarkach internetowych;
Prowadzi to głównie do utraty ruchu i zaufania klientów, a
zatem, i pieniędzy. Sprawdź reputację domeny w różnych bazach danych dla
oprogramowania antywirusowego.
Podatność:
Ryzyko:
Negatywne konsekwencje:
97%
3%
Ogólnie, 97% stron internetowych uznano za „czyste”, a tylko w 3% (1 domenie)
zaobserwowano aktywność wzbudzającą podejrzenia - nadużycie proxy/Windows.
Reputacja IP/Domeny
Dobra reputacja oznacza, że zasób sieciowy jest bezpieczny, natomiast gdy domena trafia na „czarną
listę”, antywirusy ostrzegają odwiedzających o możliwych zagrożeniach bezpieczeństwa przy próbie
odwiedzenia zasobu.
Główne wyniki OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

14. 14/34
bezpieczeństwa które umożliwia przeglądarkom
internetowym dostęp do serwera sieciowego wyłącznie
po protokole HTTPS. To gwarantuje brak możliwości
wykonania jakiegokolwiek niezabezpieczonego
połączenia HTTP, podatnego na atak.
Obecnie, wszystkie wiodące przeglądarki wspierają
zabezpieczenie ścisłego transportu HTTP (ang. HTTP
strict transport security), z wyjątkiem Opera Mini i
poprzedniej wersji Internet Explorer.
Nagłówek X-Frame-Options-Header zapewnia ochronę
przed atakiem Clickjacking, nie pozwalając pływającym
ramkom załadować się na stronie. Wspierany jest przez
IE8+, Chrome 4.1+, Firefox 3.6.9+, Opera 10.5+, Safari
4+.
Nagłówek Expect-CT zapobiega używaniu niepoprawnie
wystawionych certyfikatów poprzez umożliwianie
stronom tworzenia raportów, w celu zapewnienia
dodatkowej zgodności z wymaganiami transparentności
dot. certyfikatów. Gdy ten nagłówek jest włączony,
strona odpytuje przeglądarkę, aby sprawdzić, czy
certyfikat pojawia się w publicznych rejestrach CT.
X-Content-Type-Options - nagłówek X-Content-Type
dostarcza środków zapobiegających nasłuchowi MIME
(ang. MIME wiretapping). Nakazuje przeglądarce
stosować się do typów MIME wyszczególnionych w
nagłówku. Jako funkcja mająca na celu detekcję formatu
ściągniętego pliku, wykrywanie typów MIME (ang. MIME
sniffing) może być wykorzystane do ataków
polegających na wywoływaniu skryptów pomiędzy
stronami (Cross-site scripting).
Feature-Policy-Header pozwala na włączenie lub
wyłączenie funkcji przeglądarki, zarówno w swojej ramce
jak i w treści ramki osadzonej (<iframe>).
Gdy przeglądarka wysyła zapytanie o stronę do serwera
sieciowego, serwer odpowiada treścią opatrzoną
nagłówkiem odpowiedzi HTTP (ang. HTTP response
header). Niektóre z tych nagłówków zawierają meta-dane,
takie jak Content-Encoding (zakodowanie treści),
Cache-Control (kontrola pamięci podręcznej), kody
statusów, itd. Wraz z powyższym, istnieją również nagłówki
bezpieczeństwa HTTP, które mówią przeglądarce jak
zachowywać się w działaniu z treścią strony. Na przykład,
za pomocą Strict-Transport-Security (ścisłe
bezpieczeństwo transportowe), można zmusić przeglądarkę
do interakcji wyłącznie po protokole HTTPS. Poniżej,
przyglądamy się sześciu różnym nagłówkom
bezpieczeństwa HTTP (kolejność przypadkowa), o których
należy wiedzieć, i które zalecamy zastosować w miarę
możliwości.
Content-Security-Policy (także „Content Protection Policy”,
CSP) - nagłówek ten dostarcza dodatkową warstwę
zabezpieczającą. Polityka ta pozwala zapobiegać atakom,
takim jak Cross-Site scripting (XSS), i innym atakom
opartym na kodzie, poprzez identyfikację zatwierdzonych
źródeł treści, pozwalając przeglądarce na ściąganie ich.
Obecnie, wszystkie wiodące przeglądarki oferują pełne lub
częściowe wsparcie dla polityk bezpieczeństwa treści. To
nie zakłóca dostarczania treści; jeśli treść zostanie
dostarczona do starszej przeglądarki, po prostu nie będzie
wykonywana.
X-XSS-Protection - nagłówek ten jest skonstruowany tak,
aby włączyć filtr przeciwko uruchamianiu skryptów między
stronami (XSS), wbudowany we współczesne przeglądarki
internetowe. Zazwyczaj, filtr ten jest włączony domyślnie,
ale zastosowanie tego nagłówka wykona owe filtrowanie.
Jest wspierany przez InternetExplorer 8+ i
HTTP Strict Transport Security (HSTS) - Nagłówek
Strict-Transport-Security-Header odzwierciedla ulepszenie
Ocena Nagłówków Bezpieczeństwa HTTP
i Polityki Bezpieczeństwa Treści
Główne wyniki OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

15. 15/34
wada w nagłówkach bezpieczeństwa;
Przeprowadzenie ataków, których celem są użytkownicy, takich jak zastrzyk
złośliwego kodu, XSS, złośliwa modyfikacja treści zasobu sieciowego;
nieautoryzowany dostęp do danych, czy kontrola
atakującego nad zasobem sieciowym.
Podatność:
Ryzyko:
Negatywne konsekwencje:
91%
9%
Wyniki pokazują, że 9% domen uzyskało wysoką ocenę, a 91% - średnią ocenę.
Content-Security-Policy (CSP) - to jedna z głównych metod ograniczania ryzyka wynikającego z
ataków XSS (Cross-site scripting). Za pomocą polityki bezpieczeństwa treści (CSP), administrator
strony może definiować atrybuty dozwolone na stronach – czcionki, style, obrazki, skrypty JS, SWF, itd.
Ocena Nagłówków Bezpieczeństwa HTTP
i Polityki Bezpieczeństwa Treści
Główne wyniki OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

16. 16/34
Wsparcie dla RC4 Badacze stwierdzili, że w krótkim czasie można odszyfrować
dane ukrytych za pomocą szyfru RC4.
Renegocjaja SSL Bezpieczna renegocjacja SSL obniża ryzyko ataków DoS (ang.
Denial of Service) czy MITM (ang. Man in the Middle).
Podatność Ticketbleed Atakujący może zdalnie wyciągnąć fragmenty treści w pamięci
serwera za pomocą pola session_ID protokołu TLS.
Podatność Heartbleed Uzyskiwanie dostępu do danych przechowywanych w pamięci
klienta lub serwera.
Podatność CVE-2016-2017 Atakujący może wykorzystać tę podatność zdalnie, aby
wyciągnąć tekst z zaszyfrowanych pakietów, za pomocą techniki
„Oracle Padding”.
Podatność Beast Atakujący może odszyfrować dane wymieniane pomiędzy dwoma
stronami poprzez TLS1.0, SSL 3.0 i wcześniejsze wersje.
Podatność ROBOT Całkowicie narusza prywatność TLS gdy RSA jest używane do
uzyskania klucza sesji.
Podatność na atak Logjam Podobnie do podatności Freak, Logjam polega na obniżeniu stopnia
szyfrowania do poziomu eksportowego, na którym długość klucza
wynosi 512 bitów.
Podatność FREAK Atakujący może zmusić użytkownika i serwer do użycia kluczy
„eksportowych”, które mają bardzo ograniczoną długość, podczas
gdy on nawiązuje połączenie i wymienia dane.
Podatność POODLE Pozwala na odszyfrowywanie danych użytkownika.
Wsparcie dla słabych parametrów
algorytmu Diffiego-Hellmana
Słabe parametry mogą być użyte w celu wymiany kluczy po
Protokole Diffiego-Hellmana, który obniża bezpieczeństwo
zasobu sieciowego.
Ogólna ocena ustawień SSL, według zasobu SSL Labs. Zależy od
wielu czynników: poprawność certyfikatu, ustawienia serwera,
algorytmy wspierane przez serwer, itd. Zakres ocen od A+ do F.
Ocena
Krótki opisNazwa sprawdzenia
Wybraliśmy następujące sprawdzenia SSL/TLS:Szyfrowanie ruchu
Główne wyniki OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

17. 17/34
Istotą ataku jest kierowanie przez atakującego ruchu sieciowego ofiary przez urządzenie hakera (co jest możliwe
poprzez zmianę parametrów serwera DNS, czy modyfikację pliku „hosts” na urządzeniu ofiary). Ofiara sądzi, że ma
bezpośredni dostęp do strony swojego banku, podczas gdy jej ruch przechodzi przez pośredni węzeł atakującego,
który otrzymuje wszystkie dane wysyłane przez użytkownika (login, hasło, PIN, etc.).
Jeden z najistotniejszych elementów sprawdzenia to
ustawienia SSL/TLS, ponieważ w tych czasach, te
protokoły kryptograficzne są najpopularniejszą metodą
zapewniającą wymianę danych przez Internet. W 2019
r., twórcy przeglądarek FireFox, Safari, Edge i Chrome
oznajmili, że w 2020 r., począwszy od marca,
przeglądarki zaprzestaną wsparcia dla TLS 1.0 i 1.1.
Zalecamy przejście na TLS 1.2, albo lepiej, na TLS 1.3,
bo inaczej wyskoczy błąd w przeglądarkach.
Czynniki ryzyka: Przechwyt danych - to jeden z kilku
typów ataków, występujących w ramach jednej
kategorii: “man in the middle”. Każdy atak „man in the
middle”, albo MITM, implikuje obecność pośrednika
(osoby lub urządzenia), który ma możliwość
przechwycenia i modyfikacji danych wysyłanych
pomiędzy dwoma użytkownikami sieci, którzy, co do
zasady, nie podejrzewają, że hakerzy ingerują w
wymianę informacji między nimi.
Wybraliśmy następujące sprawdzenia SSL/TLS:Szyfrowanie ruchu
Wsparcie dla NPN i ALPN Pozwala na wskazanie, który protokół ma być wykorzystany po
uzyskaniu bezpiecznego połączenia SSL/TLS pomiędzy klientem
i serwerem.
Wsparcie dla SSL 2.0 i SSL 3.0 Oba protokoły uważa się za przestarzałe i pełne podatności,
zatem zaleca się wyłączenie ich po stronie serwera.
Wersja TLS
Protokół TLS szyfruje wszystkie rodzaje ruchu internetowego,
zabezpieczając wymianę danych w Internecie.
Właściwość niektórych protokołów negocjacji klucza, która
zapewnia, że klucze sesji nie są naruszane, nawet jeśli został
naruszony prywatny klucz serwera.
Wsparcie dla ForwardSecrecy
KrótkiopisNazwasprawdzenia
Główne wyniki OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

18. 18/34
brak lub niepoprawna konfiguracja SSL/TLS;
Przechwyt danych w wyniku ataków MITM. Takie ataki wskazują na istnienie
pośrednika (człowieka lub urządzenia), zdolnego do przechwytu i modyfikacji danych
wysyłanych pomiędzy dwoma użytkownikami sieci, którzy zazwyczaj nie podejrzewają
ingerencji hakerów w wymianie informacji pomiędzy nimi.
Atakujący mogą uzyskać dostęp do wszystkich informacji
użytkownika (login, hasło, PIN, etc.), które mogły być wysłane. Prowadzi do wycieku danych
klientów i strat finansowych.
Podatność:
Ryzyko:
Negatywne konsekwencje:
276
Nie
powiodło
się
Przeszedł
Spośród 33 domen, 27 domen spełnia to kryterium na liście kontrolnej cyber-bezpieczeństwa.
Szyfrowanie ruchu
Wyniki banków w odniesieniu do sprawdzenia ustawień SSL / TLS:
Główne wyniki OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

19. 19/34
pracownicy używający firmowego adresu e-mail banku w celach rejestracji na
różnych serwisach internetowych. Bardzo często, w 90% przypadków, użytkownicy używają
tego samego hasła w różnych serwisach.
Hakerzy mogą uzyskać dostęp do korespondencji i dokumentacji firmowej. Dostęp
do wrażliwych informacji uzyskany przez hakerów może być użyty do ataku na system
informatyczny banku.
nieautoryzowany dostęp do danych, straty finansowe i
pogorszenie reputacji.
Podatność:
Ryzyko:
Negatywne konsekwencje:
Tylko 13 banków spośród 33 spełniło to kryterium na liście kontrolnej cyber-bezpieczeństwa.
Wyciek informacji
W dzisiejszych czasach, informacja odgrywa większą rolę w życiu każdej firmy czy organizacji rządowej,
niż odgrywała parę dekad temu. Kto ma informacje, ten ma władzę, a ten kto posiada informacje innych
ludzi, ten jest lepiej przygotowany, aby konkurować ze swymi rywalami. Wszelkie wycieki informacji mają
negatywne skutki ekonomiczne dla danej firmy.
3
9
%
P
rzeszedł
Główne wyniki OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE
6
1%
N
ie
pow
io
dło
się

20. 20/34
z punktu widzenia najlepszych praktyk bezpieczeństwa, serwer sieciowy nie
powinien mieć otwartych portów, oprócz tych obsługujących usługi sieciowe.
nieautoryzowany dostęp i kontrola hakerów nad wewnętrznymi zasobami
informatycznymi.
nieautoryzowany dostęp do danych, straty finansowe i
pogorszenie reputacji.
Podatność:
Ryzyko:
Negatywne konsekwencje:
88%
Przeszedł
12%
N
ie
pow
iodło
się
Spośród 33 banków, tylko 29 banków spełniło to kryterium listy kontrolnej.
Bezpieczeństwo sieciowe (otwarte porty)
Przeanalizowaliśmy porty, które nie są używane bezpośrednio przez sam serwer sieciowy (porty 80 i 443).
Główne wyniki OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

21. 21/34
W dzisiejszych czasach, niemal wszystkie irytujące wiadomości mailowe są
wysyłane ze sfałszowanych adresów. Ofiary, których adresy są wykorzystywane
do takich celów, często ponoszą konsekwencje w formie pogorszonej reputacji,
odpowiedzialności za nadużywanie adresu mailowego, i muszą poświęcać na
sortowanie przypadkowo przesłanych wiadomości o błędach (Źródło:
OpenSpf.org). Ten test sprawdza czy potwierdzasz swoje lokalne adresy
wysyłające. Fałszowanie adresu mailowego znajdującego się w polu FROM to
typowa praktyka spamowa. SPF (ang. Sender Policy Framework) to metoda
zapobiegania fałszowaniu tego typu – zapis SPF jest tworzony na serwerze DNS,
określając i ograniczając adresy hostów którym pozwala się wysyłać pocztę
elektroniczną za pomocą nazwy twojej domeny.
Test serwera SPF
Test wyszukiwania
odwrotnego DNS
Wiele serwerów poczty elektronicznej weryfikuje tożsamość domeny wysyłającego
poprzez wyszukiwanie odwrotne. Jeśli test się nie powiedzie, komunikacja z
serwerem wysyłającym może być zablokowana. Różne serwisy reputacyjne mogą
dać niższą ocenę dla systemu w przypadku braku informacji zwrotnej.
Aby maile mogły być wysyłane i odbierane prawidłowo, poprawna domena musi
mieć odpowiadający wpis MX w DNS, który zawiera informację w 3 częściach:
nazwa domeny, nazwa hosta (na przykład, servername.domain.com) oraz IP.
Zapytanie o konwersję nazwy hosta do adresu IP nazywamy wyszukiwaniem
bezpośrednim (ang. Direct search). Wyszukiwanie odwrotne (ang. Reverse lookup)
to ten sam proces, tylko że odwrócony: konwersja IP do nazwy hosta. Wiele
serwerów poczty elektronicznej weryfikuje tożsamość domeny wysyłającego
poprzez wyszukiwanie odwrotne. Jeśli test się nie powiedzie, komunikacja z
serwerem wysyłającego może być zablokowana. Różne serwisy reputacyjne mogą
dać niższą ocenę dla systemu w przypadku braku informacji zwrotnej.
MX ConnectionTest Jeśli port 25 ma zablokowany dostęp zewnętrzny na samym serwerze MX,
serwer nie będzie mógł otrzymywać wiadomości przychodzących (serwery
wysyłające nigdy nie będą wyszukiwały alternatywnego portu). Port musi być
dostępny przynajmniej poprzez serwer proxy czy router.
Jeśli 3 porty są otwarte (25, 465 i 587), system wymaga uwierzytelniania
(AUTH) na porcie 587 zanim zostanie wysłana komenda MAIL FROM. Jeśli
połączenie do portu 25 czy 465 nie powiedzie się, ocena jest obniżana.
Krótki opisNazwa sprawdzenia
Bezpieczeństwo poczty elektronicznej
Ponad 90% ruchu e-mail zawiera spam, phishing, oprogramowanie złośliwe, i inne zagrożenia
elektroniczne. E-mail jest głównym wektorem dla zakażeń oprogramowaniem typu „ransomware” i
„malware”. To sprawdzenie ma na celu zweryfikowanie, czy serwer poczty elektronicznej zasobu
sieciowego jest poprawnie skonfigurowany pod kątem zapobiegania tym pospolitym zagrożeniom.
Główne wyniki OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

22. 22/34
Bezpieczeństwo poczty elektronicznej
Test Połączenia i
Uwierzytelnienia IMAP
Początkowo, IMAP wspierał szyfrowane mechanizmy logowania, ale to
zabezpieczenie można obejść za pomocą logowania tekstem jawnym
poprzez port 143. Zatem, treść wiadomości jest podatna na ingerencję i
utratę prywatności. Sprawdza port używany do IMAP. Domyślny,
niezabezpieczony port dla połączeń IMAP to 143. Bezpieczny, szyfrowany
port to 993.
If a POP3 connection uses standard port 110, the connection is not secure
and can be hacked, which can lead to loss of messages and privacy.
Checks which port is used by POP3. If a POP3 connection uses the standard
port 110, the connection is not secure and may be disrupted, resulting in
potential loss of messages and privacy.
Test połączenia POP3
Test na uwierzytelnianie
tekstu jawnego SMTP
Spamerzy mogą zhakować konta użytkowników zbierając hasła wysyłane do
serwera w tekście jawnym za pomocą mechanizmów PLAIN czy AUTH
LOGIN.
Ten test wykonuje próbę połączenia do serwera pocztowego poprzez porty
25 i 465. Dla każdego połączenia, sprawdza listę dostępnych metod
uwierzytelniających.
Server otrzyma najniższą ocenę jeśli port 25 wspiera PLAIN czy AUTH
LOGIN. Najwyższą ocenę przyznaje się, jeśli SMTP SSL jest włączone i
mechanizmy PLAIN i AUTH LOGIN są niedostępne na porcie 25. Warto
zaznaczyć, że, jeśli AUTH nie jest wspierany, server MX spełnia kryterium,
ponieważ nie można nasłuchiwać hasła w tekście jawnym.
Jeśli serwer pozwala na wysyłanie wiadomości do adresów nielokalnych (przez
nieautoryzowanych wysyłających lub niezaufane adresy IP), uważa się to za
otwarty przekaźnik. Zatem, serwer może być użyty przez spamerów, i przez
to znaleźć się na czarnej liście.
Test na otwarty
przekaźnik i format
wiadomości email
Jeśli twój serwer nie wspiera testu SPF, mogą wyniknąć z tego 2 problemy:
1) Ponosisz ryzyko odbierania i przetwarzania większej ilości spamu, co
zwiększa obciążenie zasobów systemowych.
2) Ponosisz ryzyko obsługi większej liczby niedopuszczalnych niepowodzeń i
niepowodzeń dostarczenia – zjawisko to znane jest jako „backscattering”.
Test klienta SPF
Jeśli adres IP należący do twojej sieci znajdzie się na „czarnej liście”, serwery
poczty elektronicznej stosujące DNSBL blokują komunikację z twoim
serwerem.
Czarna lista oparta na DNS sprawdza adresy IP związane ze spamem i innym
oprogramowaniem złośliwym.
Test weryfikacji DNSBL
KrótkiopisNazwasprawdzenia
Główne wyniki OCENARYZYKATELEINFORMATYCZNEGOBANKÓWWPOLSCE

23. 23/34
niepoprawna konfiguracja serwera pocztowego przeglądarki.
e-mail jest głównym wektorem dla zakażeń oprogramowaniem typu „ransomware” i
„malware”.
otrzymywanie niechcianych wiadomości zawierających
bezużyteczne informacje i kod złośliwy (botnety, trojany, robaki), jeden z wektorów phishingu.
Podatność:
Ryzyko:
Negatywne konsekwencje:
67% badanych banków ma wysoką ocenę bezpieczeństwa poczty
elektronicznej, 29% - średnią, a 4% - niską.
Bezpieczeństwo poczty elektronicznej
Wyniki banków w sprawdzeniu zasobu sieciowego serwera pocztowego
Główne wyniki OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE
Niska stawkaŚrednia stawkaWysoka ocena
29%4%
67%

24. 24/34
obecność oprogramowania złośliwego, programy wyłudzające, takie jak
cryptojacking, itp.
cryptojacking (znane również jako przejściowe kopanie kryptowalut) jest najbardziej
powszechną formą oprogramowania złośliwego polegającego na kopaniu kryptowalut. Co do
zasady, to oprogramowanie działa ze skryptami, które są uruchamiane na stronie, co pozwala
wyszukiwarce ofiary automatycznie kopać kryptowaluty podczas wizyty. Te koparki sieciowe
są zaimplementowane po kryjomu na różnych stronach, niezależnie od ich popularności czy
kategorii.
nieautoryzowany dostęp do informacji, obejście istniejących zasad
kontroli dostępu, obniżenie wydajności, błędy systemu i niedostępność usług.
Podatność:
Ryzyko:
Negatywne konsekwencje:
100% banków przeszło sprawdzenie na zhakowanie zasobów, na podstawie oznak zewnętrznych.
10
0
%
Stan obecny
Sprawdzenie, czy zasób został zhakowany, na podstawie oznak zewnętrznych.
• Obecność złośliwych skryptów na stronie;
• Obecność ukrytej sieci koparek kryptowalut;
• Sprawdzenie prędkości strony;
• Skargi użytkowników odnośnie obecności wirusów na stronie, wykrytych przez oprogramowanie
antywirusowe;
• Obecność strony na " czarnej liście " baz danych reputacji przeglądarek internetowych;
Główne wyniki OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

25. 25/34
zidentyfikowane podatności mogą pozostać nieznane właścicielom zasobu
sieciowego.
podatność może być wykorzystana przez hakerów.
nieautoryzowany dostęp do informacji, obejście istniejących zasad
rozróżniania dostępu, utrata produktywności, usterki i niedostępność usług.
Podatność:
Ryzyko:
Negatywne konsekwencje:
10
0
%
100% banków nie spełniło kryterium zgodności z Security.txt.
Zgodność z security.txt
Kiedy niezależni badacze cyberbezpieczeństwa wykrywają zagrożenie w usłudze internetowej, często nie
mają odpowiednich kanałów komunikacji do zgłoszenia podatności właścicielowi usługi internetowej. W
takim wypadku, nie zgłasza się żadnych problemów z bezpieczeństwem. Security.txt definiuje normę
pomagającą organizacjom określać, jak badacze cyberbezpieczeństwa mogą bezpiecznie ujawniać
podatności.
Główne wyniki OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

26. 26/34
pliki „cookie” mogą przechować wiele danych, wystarczających do identyfikacji
użytkownika bez wiedzy ani zgody. W większości przypadków, użytkownicy strony internetowej
muszą zaakceptować wszystkie zasady przechowywania i przetwarzania ich danych
osobowych.
nieautoryzowane czy nielegalne przetwarzanie danych osobowych klientów.
niezgodność z ustawodawstwem i wymaganiami normatywnymi.
Podatność:
Ryzyko:
Negatywne konsekwencje:
Spośród 33 banków, jedynie 8 spełnia to kryterium na liście kontrolnej cyber-bezpieczeństwa.
Zgodność z RODO
Dane osobowe muszą być przetwarzane w sposób zapewniający odpowiednie bezpieczeństwo, w tym ochronę
przeciwko nieautoryzowanemu czy nielegalnemu przetwarzaniu jak również i przypadkowej utracie, zniszczeniu czy
uszkodzeniu, za pomocą odpowiednich środków technicznych i organizacyjnych („integralność i poufność”).
Zgodnie z RODO (Regulacja o Ochronie Danych Osobowych) i Dyrektywą dotycząca przetwarzania danych
osobowych i ochrony prywatności w sektorze łączności elektronicznej (Dyrektywa o prywatności i
łączności elektronicznej), wymaga się, aby strony internetowe dostarczały
24%
8
Przeszedł
Główne wyniki OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE
76%
25
N
ie
pow
iodło
się

27. 27/34
W wyniku badania bezpieczeństwa zasobów
sieciowych banków w Polsce, stwierdzono średni
poziom implementacji publicznie dostępnych
zaleceń odnośnie konfiguracji serwerów
sieciowych i elementów z nimi związanych.
Uzyskawszy ogólny obraz bezpieczeństwa
zasobów sieciowych banków wywnioskowano, że:
wiele banków zaniedbuje nawet najbardziej
powszechne i łatwe w zastosowaniu środki
podnoszące bezpieczeństwo zasobów
sieciowych.
Sprawdziwszy zasoby sieciowe banków zgodnie z
kryteriami opisanymi powyżej, stwierdzono, że
dość dobrze poznane podatności i problemy z
bezpieczeństwem są wciąż obecne w zasobach
sieciowych banków w Polsce. Obecna sytuacji
pozwala atakującym liczyć na powodzenie w
atakach na w/w organizacje finansowe.
Wnioski OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

28. 28/34
Badanie przeprowadzone przez WebTotem
wskazało szereg słabych i podatnych punktów
banków w Polsce, które mogą prowadzić do
poważnych strat finansowych, a nawet do
nieodwracalnej utraty reputacji, pomimo tego, że
na pierwszy rzut oka wydają się nieistotne i trudne
do wykorzystania przez hakerów.
Obecnie, w czasach szybkiego przesyłu informacji
i dynamicznie zmieniającego się świata
cyfrowego, gwarancja poufności i integralności
danych jest priorytetem dla klientów, gdy
wybierają usługi.
Dobra wiadomość jest taka, że już dzisiaj banki w
Polsce mają wszelkie możliwości i gotowe
narzędzia, aby stworzyć system zarządzania
bezpieczeństwem informatycznym i na czas
wdrożyć środki i produkty zapewniające ich
ochronę i zrównoważony rozwój.
Podsumowanie OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

29. 29/34
Security Affairs. 2020. Crooks Hacked Polish Banks With A Malware Planted On Government Site. [online]
Available at: <https://securityaffairs.co/wordpress/56056/cyber-crime/polish-banks-malware.html>
[Accessed 16 June 2020].
5
BadCyber. 2020. Several Polish Banks Hacked, Information Stolen By Unknown Attackers. [online] Available
at: <https://badcyber.com/several-polish-banks-hacked-information-stolen-by-unknown-attackers/>
[Accessed 16 June 2020].
4
Constantin, L., 2020. Recent Malware Attacks On Polish Banks Tied To Wider Hacking Campaign. [online]
PCWorld. Available at:
<https://www.pcworld.com/article/3169413/recent-malware-attacks-on-polish-banks-tied-to-wider-hackin
g-campaign.html> [Accessed 16 June 2020].
3
ONeill, P. and ONeill, P., 2020. Hackers Break Into Polish Banks Through Government Regulator Charged
With Bank Security Standards - Cyberscoop. [online] CyberScoop. Available at:
<https://www.cyberscoop.com/hackers-break-polish-banks-government-regulator-charged-bank-security-
standards/> [Accessed 16 June 2020].
2
CybelAngel. 2020. A Major Cyberattack Targets The Polish Banking Industry. [online]
Available at: <https://cybelangel.com/blog/cyberattack-targets-polands-banks/> [Accessed 16 June 2020].
1
# URL
Źródło:
W 2017 r. systemy komputerowe kilku banków w Polsce zostały zainfekowane złośliwym oprogramowaniem
w największym w historii Polski cyberprzestępstwie w sektorze finansowym.
Ten atak na banki w Polsce to przykład zamierzonego ataku na systemy bankowe. Hakerzy użyli typowego
wektora penetracji na wewnętrzną sieć banków: odkryli i wykorzystali podatność w portalu internetowym
rządowej strony sektora finansowego i stworzyli kanał dla dostarczania złośliwego oprogramowanie do
stanowisk pracy pracowników banków.
W wyniku ataku, ucierpiało 20 banków w Polsce, odnosząc również szkody w postaci dużej utraty
danych.
Studium przypadków OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

30. 30/34
Cert.bournemouth.ac.uk. 2020. Amid COVID-19, Global Orgs See A 148% Spike In Ransomware Attacks;
Finance Industry Heavily Targeted – BU-CERT. [online] Available at:
<https://cert.bournemouth.ac.uk/amid-covid-19-global-orgs-see-a-148-spike-in-ransomware-attacks-financ
e-industry-heavily-targeted/> [Accessed 16 June 2020].
4
SDxCentral. 2020. Ransomware Attacks Spike 148% Amid COVID-19 Scams - Sdxcentral. [online] Available at:
<https://www.sdxcentral.com/articles/news/ransomware-attacks-spike-148-amid-covid-19-scams/2020/04/
> [Accessed 16 June 2020].
3
Cert.bournemouth.ac.uk. 2020. Amid COVID-19, Global Orgs See A 148% Spike In Ransomware Attacks;
Finance Industry Heavily Targeted – BU-CERT. [online] Available at:
<https://cert.bournemouth.ac.uk/amid-covid-19-global-orgs-see-a-148-spike-in-ransomware-attacks-finan
ce-industry-heavily-targeted/> [Accessed 16 June 2020].
2
VMware Carbon Black. 2020. Amid COVID-19, Global Orgs See A 148% Spike In Ransomware Attacks;
Finance Industry Heavily Targeted | Vmware Carbon Black. [online] Available at:
<https://www.carbonblack.com/2020/04/15/amid-covid-19-global-orgs-see-a-148-spike-in-ransomware-at
tacks-finance-industry-heavily-targeted/> [Accessed 16 June 2020].
1
# URL
Obecna sytuacja w związku z wirusem COVID-19
Podczas pandemii COVID-19, sektor finansowy stał się bardziej podatny. Pomiędzy lutym i marcem 2020 r.,
analitycy zaobserwowali 38% wzrost w cyberatakach na instytucje finansowe.
Zanotowano wzmożenie przejścia na pracę zdalną w skali świata i w różnych sektorach gospodarki.
Hakerzy wykorzystywali COVID-19, aby przeprowadzać ataki phishingu, wypuszczać fałszywe aplikacje /
mapy, trojany, „backdoory”, koparki krpytowalut, botnety, i oprogramowanie typu „ransomware”.
Oczywistym jest, że, podczas walki z COVID-19, hakerzy z całego świata będą dalej atakować podatne
populacje i organizacje.
Źródło:
Studium przypadków OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

31. 31/34
1 148 036
Monitorowanie polskich
firm: stron w
strefie domen .pl
Top 3 na EmergePodążanie ścieżką globalnej
innowacji poprzez naukę i
technologię, przy wsparciu rządu
USA
Top 3 na Latitude
Certyfikowani specialiści IS:
OSCP, OSCE, CEH, CHFI,
CISA, ISO 27001
Najlepsze rozwiązanie SaaS i
B2B na Szczycie Echelon Asia
w Singapurze w 2018 r.
Wdrażanie najlepszych
światowych praktyk
zapewniających
bezpieczeństwo informacji.
SYSTEM MONITOROWANIA
ZAPROJEKTOWANY W CELU OCHRONY
ZASOBÓW SIECIOWYCH PRZED
WŁAMANIAMI I CYBERZAGROŻENIAMI
WEBTOTEM
O firmie OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

32. 32/34
Podnosimy poziom
bezpieczeństwa informacji stron
firmowych na całym świecie.
Oceniać i zarządzać
ryzykiem teleinformatycznym
Otrzymywać proaktywną
ochronę przed nowymi
cyberzagrożeniami
Zapobiec hakowaniu dzięki
zaleceniom bezpieczeństwa
udzielanym krok po kroku
Misją WebTotem jest dostarczenie ludziom ze sfery
nietechnicznej rewolucyjnego produktu opartego
na sztucznej inteligencji, aby mogli chronić swoją
działalność gospodarczą jednym kliknięciem.
The
WebTotem
client can
O firmie OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

33. 33/34
Przeprowadzając audyt bezpieczeństwa, można spodziewać się
następujących korzyści:
● Nasza kompleksowa, niezależna ocena poziomu bezpieczeństwa
infrastruktury informatycznej twojej firmy. Klient otrzymuje zalecenia
odnośnie ulepszeń od wysoce wyspecjalizowanych ekspertów z wieloletnim
doświadczeniem w branży.
● Audyt WebTotem zapewnia poprawę poufności informacji komercyjnych,
itp., w celu ochrony systemów informatycznych przed nieautoryzowanym
dostępem i zagrożeniami wirusowymi
● Audyt bezpieczeństwa informacji pozwala uniknąć zbędnych kosztów
związanych z IT i bezpieczeństwem, ponieważ dostarcza jedynie zaleceń
adekwatnych dla danej firmy. Co więcej, redukuje ryzyko reputacyjne mające
swoje źródło w nieodpowiednim bezpieczeństwie informacji, co jest ważnym
aspektem w każdej działalności, czy to w banku, czy w innej
wyspecjalizowanej firmie.
● Wdrażając nasze zalecenia, oparte na audycie, klient optymalizuje
infrastrukturę IT i związane procesy zgodnie z najnowszymi wymaganiami
bezpieczeństwa, poprawiając wewnętrzną kontrolę jakości.
Stosowanie
się do naszej
ekspertyzy
zapewnia
wyższy
poziom
bezpieczeńst
wa i
minimalizuje
ryzyko dla
twojej firmy.
Audyt zasobów informacyjnych i infrastruktury firmy pozwala na identyfikację i zapobieganie potencjalnym
zagrożeniom i znacząco obniża ryzyko dla procesów biznesowych.
Audyt zawiera zestaw środków ukierunkowanych na ocenę obecnego stanu procesów związanych z
bezpieczeństwem informacji, w tym testy penetracyjne (ang. Penetration Testing), a mianowicie,
modelowanie czynności hakerów, skanowanie instrumentalne z ręczną weryfikacją podatności, i inne
metody zgodne z międzynarodowymi praktykami dużych organizacji międzynarodowych, takimi jak Web
Application Security Consortium (WASC) i Open Web Application Security Project (obecnie OWASP v.4).
Proces oceny bezpieczeństwa składa się z następujących kroków:
• implementacja ręcznych sprawdzeń i analiza otrzymanych wyników;
• weryfikacja narzędzi i aplikacji;
• badanie stwierdzonych podatności w celu określenia, jak można je wykorzystać;
• analiza bezpieczeństwa systemu w odniesieniu do zagrożeń zewnętrznych;
• badanie konfiguracji sieci bezprzewodowej;
• audyt używanych konfiguracji IP;
• stworzenie sprawozdania analitycznego i zaleceń odnośnie eliminacji zidentyfikowanych podatności.
Dlaczego warto zlecić audyt bezpieczeństwa informacji firmie zewnętrznej?
Dlaczego my? OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE

34. 34/34
Kontakt OCENA RYZYKA TELEINFORMATYCZNEGO BANKÓW W POLSCE