Praktyczne stosowanie systemów BMS w Szpitalach

Stosowanie systemów zarządzania budynkiem (BMS) w szpitalach przynosi wiele korzyści, zarówno dla personelu medycznego, pacjentów, jak i samej instytucji szpitalnej.

BMS - system zarządzania budynkami. Na czym polega system automatyki BMS? - Budowa, obiektykomercyjne.muratorplus.pl

Oto kilka powodów, dlaczego szpitale powinny stosować BMS:

  1. Optymalizacja zużycia energii: Szpitale zużywają duże ilości energii na działanie systemów HVAC, oświetlenia, sprzętu medycznego itp. BMS umożliwia monitorowanie i kontrolowanie zużycia energii w czasie rzeczywistym, co pozwala na identyfikację obszarów, w których można zaoszczędzić energię poprzez optymalizację ustawień.
  2. Poprawa komfortu pacjentów i personelu: Stosowanie BMS umożliwia utrzymanie optymalnych warunków środowiskowych w szpitalach, takich jak temperatura, wilgotność i jakość powietrza. Poprawa komfortu może przyczynić się do szybszego powrotu do zdrowia pacjentów oraz zwiększenia satysfakcji personelu.
  3. Zwiększenie bezpieczeństwa i higieny: BMS może być wykorzystywany do monitorowania i kontroli różnych aspektów bezpieczeństwa i higieny w szpitalach, takich jak systemy przeciwpożarowe, kontrole dostępu, czy monitorowanie środowiska w salach operacyjnych.
  4. Szybka reakcja na awarie: Dzięki systemom alarmowym i monitorowaniu w czasie rzeczywistym, BMS umożliwia szybką reakcję na awarie i nieprawidłowości w systemach budynku, co może być kluczowe w przypadku sytuacji krytycznych.
  5. Redukcja kosztów eksploatacji: Poprzez optymalizację zużycia energii, wykrywanie wycieków wody czy unikanie niepotrzebnego zużycia zasobów, BMS przyczynia się do zmniejszenia kosztów eksploatacji budynku.
  6. Zarządzanie zasobami w czasie rzeczywistym: BMS umożliwia zarządzanie zasobami budynku w czasie rzeczywistym, co pozwala na szybkie reagowanie na zmieniające się warunki i potrzeby.
  7. Zgodność ze standardami i przepisami: W niektórych przypadkach stosowanie BMS może być wymagane przez przepisy budowlane lub regulacje dotyczące efektywności energetycznej i bezpieczeństwa.

W sumie, stosowanie BMS w szpitalach przyczynia się do poprawy efektywności operacyjnej, zwiększenia komfortu i bezpieczeństwa, oraz zmniejszenia kosztów eksploatacji. Dlatego też coraz więcej szpitali decyduje się na wdrożenie tych zaawansowanych systemów zarządzania budynkiem.

Wprowadzenie do ISO/IEC 15408

Common Criteria, znane również jako ISO/IEC 15408, to międzynarodowy standard służący do oceny i certyfikacji cech bezpieczeństwa produktów i systemów informatycznych.

Saho 商合行

Stanowi on ramy do oceny funkcji bezpieczeństwa tych produktów i zapewnienia, że spełniają one określone wymagania bezpieczeństwa.

Standard Common Criteria został opracowany w celu ustanowienia kryteriów oceny bezpieczeństwa produktów IT, takich jak oprogramowanie, sprzęt i firmware. Jest on używany przez rządy, firmy i organizacje na całym świecie, aby podejmować świadome decyzje dotyczące bezpieczeństwa produktów, których nabywają.

Proces oceny obejmuje kilka kroków, w tym:

  1. Cel Bezpieczeństwa (ST): Pierwszym krokiem jest określenie wymagań bezpieczeństwa dla ocenianego produktu lub systemu. Dokument ten nazywa się Celem Bezpieczeństwa.
  2. Ocena Zgodności: Po ustaleniu Celu Bezpieczeństwa, przeprowadza się ocenę zgodności produktu lub systemu z tymi wymaganiami. Ocena ta obejmuje analizę dokumentacji, projektu, oraz testowanie.
  3. Certyfikacja: Po pomyślnej ocenie zgodności, produkt lub system może być certyfikowany przez odpowiedni organ certyfikacyjny. Certyfikat potwierdza, że produkt spełnia określone standardy bezpieczeństwa.
  4. Środki Ochronne: Standard Common Criteria definiuje również poziomy ochrony (tzw. EAL – Evaluation Assurance Levels), które określają, jak dokładnie produkt został przetestowany i jakie środki bezpieczeństwa zostały zastosowane.

Dzięki zastosowaniu standardu Common Criteria użytkownicy mogą mieć większą pewność co do bezpieczeństwa produktów IT, które nabywają, a producenci mogą udowodnić, że ich produkty spełniają określone standardy bezpieczeństwa.

Pojęcia systemowe HIS, LIS, PACS, RIS i CIS – ENTRAST wyjaśnia zagadnienia

W technologii opieki zdrowotnej akronimy LIS, PACS, RIS, HIS i CIS są często wymieniane, co często powoduje dezorientację specjalistów i pacjentów. Systemy te, choć różnią się funkcjonalnością, wspólnie tworzą szkielet współczesnej informatyki medycznej.

Zapewniają bezproblemowe działanie, efektywną opiekę nad pacjentem i niezawodne zarządzanie danymi w środowisku opieki zdrowotnej. W tym artykule zbadamy, co wyróżnia LIS, RIS, PACS i inne platformy.

Zrozumienie LIS, PACS, RIS, HIS i CIS

LIS, RIS, CIS, PACS i HIS to systemy medyczne stosowane w różnych środowiskach szpitalnych i klinicznych. Systemy te umożliwiają personelowi medycznemu zarządzanie wszelkiego rodzaju danymi, od informacji o pacjencie po obrazy i raporty medyczne.

Różnica między archiwami HIS, LIS, RIS, CIS i PACS

  • HIS oznacza System Informacji Szpitalnej. Jest to kompleksowy system oprogramowania, który zarządza wszystkimi aspektami opieki nad pacjentem, takimi jak planowanie wizyt, śledzenie leków i rozliczenia z ubezpieczeniem.
  • LIS oznacza laboratoryjny system informacyjny. Jest to system oprogramowania zarządzający danymi laboratoryjnymi, takimi jak wyniki badań, dane demograficzne pacjentów i informacje rozliczeniowe.
  • PACS oznacza system archiwizacji i komunikacji obrazów. Jest to system przechowujący i zarządzający obrazami medycznymi, takimi jak zdjęcia rentgenowskie, tomografia komputerowa i rezonans magnetyczny.
  • RIS oznacza system informacji radiologicznej. Jest to system oprogramowania, który zarządza przepływem pracy w radiologii, np. planowaniem badań, śledzeniem zleceń i przechowywaniem raportów.
  • CIS oznacza system informacji klinicznej. Jest to podzbiór HIS, który koncentruje się na zarządzaniu danymi klinicznymi, takimi jak diagnozy pacjentów, leki i alergie.

Oto tabela podsumowująca kluczowe różnice między tymi systemami:

System Przeznaczenie systemu Klasyfikacja informacji
LIS Zarządzaj danymi laboratoryjnymi Wyniki badań, dane demograficzne pacjentów, informacje rozliczeniowe
PACS Przechowuj i zarządzaj obrazami medycznymi Zdjęcia rentgenowskie, tomografia komputerowa, rezonans magnetyczny itp.
RIS Zarządzaj przepływem pracy w radiologii Planowanie badań, śledzenie zleceń, przechowywanie raportów

 

HIS Zarządza wszystkimi aspektami opieki nad pacjentem Wizyty, leki, fakturowanie itp.

 

CIS Zarządzaj danymi klinicznymi

 

Diagnozy, leki, alergie itp.

 

Wzajemne powiązania nowoczesnych systemów opieki zdrowotnej

Chociaż każdy z tych systemów – LIS, PACS, RIS, HIS i CIS – ma swoją odrębną rolę, niezwykle istotne jest rozpoznanie ich wzajemnych powiązań w szerszym krajobrazie opieki zdrowotnej. Razem usprawniają operacje, poprawiają opiekę nad pacjentem i zapewniają pracownikom służby zdrowia dostęp do potrzebnych danych wtedy, gdy ich potrzebują.

W miarę ciągłego rozwoju opieki zdrowotnej wraz z postępem technologicznym integracja tych systemów staje się jeszcze ważniejsza. Nie tylko poprawiają efektywność, ale także przyczyniają się do lepszych wyników leczenia pacjentów, zapewniając szybki dostęp do dokładnych informacji. Na przykład płynna integracja PACS i RIS może przyspieszyć proces diagnostyczny, umożliwiając szybsze podejmowanie decyzji dotyczących leczenia.

Co więcej, w miarę jak opieka skoncentrowana na pacjencie staje się normą, systemy te odgrywają kluczową rolę w zapewnianiu, że pacjenci są informowani, zaangażowani i znajdują się w centrum swojej podróży opiekuńczej. Rozumiejąc niuanse i funkcjonalności każdego systemu, pracownicy służby zdrowia mogą lepiej wykorzystać je w celu zapewnienia optymalnej opieki.

W przyszłości możemy spodziewać się jeszcze ściślejszej integracji między tymi systemami, napędzanej postępami w sztucznej inteligencji i uczeniu maszynowym. Zwiększy to jeszcze bardziej dokładność danych, analizę predykcyjną i spersonalizowaną opiekę nad pacjentem.

W Polsce głównymi dostawcami systemów są:

  1. Asseco – AMMS – Klientami Asseco Poland S.A. jest ponad 450 największych szpitali w Polsce oraz większość polskich Centrów Krwiodawstwa i Krwiolecznictwa. Asseco współpracuje z jednostkami Narodowego Funduszu Zdrowia  zarówno na płaszczyźnie infrastruktury IT, jak i oprogramowania. Wszystkie placówki lecznictwa uzdrowiskowego do rozliczania swoich usług z NFZ stosują aplikację internetową, dostarczoną i wdrożoną przez spółkę Asseco. Ponadto,  w dużej części jednostek lecznictwa otwartego w kraju funkcjonuje oprogramowanie wspomagające ewidencję i rozliczanie wizyt pacjentów, znane pod nazwą mMedica. Oferowane rozwiązania pozwalają na kompleksową informatyzację jednostek służby zdrowia różnych wielkości, o różnych profilach działalności.  Firma stale wzbogaca ofertę i inwestuje w nowe technologie.
  2. Comarch – OptiMED – jest nowoczesnym polskim rozwiązaniem w dziedzinie kompleksowych systemów informatycznych przeznaczonych do obsługi placówek służby zdrowia. Obecna wersja systemu powstała na bazie kilkunastoletnich doświadczeń w pracy z ośrodkami medycznymi. System został zainstalowany i jest używany w wielu szpitalach w Polsce, a liczba sprzedanych licencji stanowiskowych przekracza półtora tysiąca. Obecnie w swojej ofercie firma posiada pełen zakres modułów wymaganych do informatyzacji placówki ochrony zdrowia, zarówno w tak zwanej  części białej,  jak i szarej. OPTIMED posiada budowę modułową i może być konfigurowany zgodnie z wymaganiami klienta. System jest przygotowany do obsługi kart mikroprocesorowych z danymi pacjentów oraz personelu  placówek służby zdrowia.
  3. CompuGroup Medical – CLININET – jest kompleksowym rozwiązaniem obejmującym wszystkie obszary funkcjonowania szpitala i poradni („część biała”, „część szara”). System został stworzony z myślą o potrzebach  polskich szpitali i lecznictwa otwartego. Modułowa budowa zapewnia dopasowanie do wymogów funkcjonalnych i wybór dowolnego interfejsu (znakowy i/lub graficzny). Spośród innych systemów obecnych na rynku CLININET  wyróżnia się unikalną technologią, która  umożliwia pełną obsługę części medycznej systemu przy użyciu przeglądarki WWW.  W procesie kreacji  systemu wykorzystywane są takie technologie, jak AJAX, Java, J2EE, JavaScript. Główne cechy i korzyści systemu CLININET: – Kompleksowe i elastyczne rozwiązanie zbudowane w oparciu o najlepsze na rynku komponenty. -Cyfrowa diagnostyka obrazowa (PACS).
  4. Nexus Polska – ESKULAP – Nexus Polska koncentruje swoje działania niemalże wyłącznie na rynku ochrony zdrowia. Spółka, od początku istnienia, jest zaangażowana w tworzenie sztandarowego produktu firmy, systemu klasy HIS – Eskulap. Eskulap jest kompleksowym, wielofunkcyjnym systemem informatycznym przeznaczonym dla podmiotów leczniczych realizujących zadania zarówno z obszaru lecznictwa zamkniętego, jak i otwartego. Składa się z kilkudziesięciu modułów przeznaczonych dla użytkowników pełniących różne role w organizacji jednostki medycznej. Oczekiwania klientów, adaptowane do sytemu od wielu lat przez szerokie grono jego odbiorców (obecnie ponad 120 podmiotów), pozwalają uznać, że posiada on najszerszy zakres funkcjonalny z dostępnych na rynku rozwiązań klasy HIS

Podsumowując, choć akronimy mogą na pierwszy rzut oka wydawać się przytłaczające, zrozumienie różnic i synergii pomiędzy LIS, PACS, RIS, HIS i CIS ma fundamentalne znaczenie dla każdego pracownika służby zdrowia. Wdrożenie i optymalizacja tych systemów to krok naprzód w trwającym procesie podnoszenia standardów opieki zdrowotnej na całym świecie, ENTRAST w tym zakresie wspiera RP.

„Zarządzanie incydentami związanymi z ICT, ich klasyfikacja i zgłaszanie” wg rozporządzenia DORA

Kluczowym wymogiem do osiągnięcia wysokiego wspólnego poziomu operacyjnej odporności cyfrowej podmiotów finansowych jest zgłaszanie poważnych incydentów związanych z ICT do właściwym organów oraz dobrowolne informowanie ich o znaczących cyberzagrożeniach1.

W dobie gospodarki cyfrowej stale rośnie zagrożenie związane z cyberatakami, czego przykładem mogą być ataki DDoS czy ransomware. Jednocześnie działalność podmiotów finansowych może być zakłócona przez wystąpienie błędów ludzkich bądź awarii technicznych, które mają wpływ na funkcjonowanie sieci i systemów informatycznych z których podmioty te korzystają. Skutki takich zdarzeń mogą być bardzo dotkliwe, nie tylko w kontekście możliwych strat dla podmiotów finansowych spowodowanych niedostępnością usług dla ich klientów. Mogą one również ograniczać zaufanie do rynku finansowego, w szczególności w przypadku dużej skali incydentu i nagłośnienia go przez media.

Z jednej strony istotne jest podejmowanie przez podmioty finansowe działań, które będą zapobiegać takim zdarzeniom, a z drugiej sprawne realizowanie działań naprawczych, aby łagodzić ich skutki. Z perspektywy oceny ryzyka w kontekście cyberbezpieczeństwa, informacje o incydentach związanych z ICT są przy tym kluczowe dla właściwych organów nadzorujących podmioty finansowe w ramach Rozporządzenia DORA.

Do realizacji tych założeń służą przepisy rozdziału III Rozporządzenia DORA – „Zarządzanie incydentami związanymi z ICT, ich klasyfikacja i zgłaszanie”. Wymogi tego rozdziału są uzupełnione o przepisy dotyczące cyberzagrożeń oraz znaczących cyberzagrożeń, ze względu na ich powiązanie z obszarem incydentów.

DORA Regulations: What You Need to Know – Reflectiz

Artykuł ten poświęcony jest przeglądowi wymagań Rozporządzenia DORA w obszarze zarządzania incydentami związanymi z ICT oraz klasyfikacji i dobrowolnego powiadamiania o znaczących cyberzagrożeniach. Zagadnienia te mają istotne znaczenie dla podmiotów, które są objęte wymogami Rozporządzenia DORA. Krąg adresatów tych wymagań jest szeroki, a zbliżający się termin rozpoczęcia stosowania Rozporządzenia DORA pozostawia coraz mniej czasu na zapewnienie zgodności prowadzonej działalności z omawianymi obowiązkami. Co ważne, przepisy Rozporządzenia DORA są stosowane bezpośrednio i nie wymagają implementacji do prawa krajowego.

Zagadnienia ujęte w tym artykule koncentrują się wokół roli definicji zawartych w Rozporządzeniu DORA i odnoszących się do incydentów związanych z ICT oraz cyberzagrożeń. Artykuł zawiera także przegląd obowiązków w obszarze zarządzania incydentami związanymi z ICT, które wynikają z Rozporządzenia DORA. W ramach kolejnych opracowań publikowanych na stronie KNF w zakresie Rozporządzenia DORA, omawiane obowiązki zostaną szczegółowo przybliżone.

Rola definicji w wyznaczeniu zakresu obowiązków z Rozporządzenia DORA w kontekście incydentów związanych z ICT oraz cyberzagrożeń

Omawianie wymagań Rozporządzenia DORA w obszarze zarządzania incydentami związanymi z ICT oraz dotyczących klasyfikacji i dobrowolnego powiadamiania o znaczących cyberzagrożeniach rozpoczniemy od definicji najważniejszych pojęć. Pełnią one kluczową rolę dla wyznaczenia zakresu wymienionych obowiązków.

Incydent związany z ICT2 – pojedyncze zdarzenie lub seria powiązanych ze sobą zdarzeń, nieplanowanych przez dany podmiot finansowy, które zagrażają bezpieczeństwu sieci i systemów informatycznych i mają negatywny wpływ na dostępność, autentyczność, integralność lub poufność danych lub na usługi świadczone przez ten podmiot finansowy

Poważny incydent związany z ICT3 – incydent związany z ICT o dużym negatywnym wpływie na sieci i systemy informatyczne, które wspierają krytyczne lub istotne funkcje podmiotu finansowego

W tych dwóch definicjach użyto innych pojęć, które są już zdefiniowane w Rozporządzeniu DORA, a są to:

  • sieci i systemy informatyczne4 – sieci i systemy informatyczne zdefiniowane w art. 6 pkt 1 dyrektywy (UE) 2022/25555. Uwzględniając odesłanie do dyrektywy NIS2, pojęcie sieci i systemy informatyczne, na gruncie Rozporządzenia DORA, obejmuje:
    • sieć łączności elektronicznej zdefiniowaną w art. 2 pkt 1 dyrektywy (UE) 2018/1972;
    • urządzenie lub grupę wzajemnie połączonych lub powiązanych urządzeń, z których co najmniej jedno, na podstawie programu, automatycznie przetwarza dane cyfrowe; lub
    • dane cyfrowe przechowywane, przetwarzane, pobierane lub przekazywane przez elementy określone w lit. a) i b) w celu ich eksploatacji, użycia, ochrony i utrzymania6.
  • bezpieczeństwo sieci i systemów informatycznych7 – bezpieczeństwo sieci i systemów informatycznych zdefiniowane w art. 6 pkt 2 dyrektywy (UE) 2022/2555 Uwzględniając odesłanie do dyrektywy NIS28, pojęcie bezpieczeństwo sieci i systemów informatycznych, na gruncie Rozporządzenia DORA, obejmuje odporność sieci i systemów informatycznych, przy danym poziomie zaufania, na wszelkie zdarzenia, które mogą naruszyć dostępność, autentyczność, integralność lub poufność przechowywanych, przekazywanych lub przetwarzanych danych lub usług oferowanych przez te sieci i systemy informatyczne lub dostępnych za ich pośrednictwem.
  • krytyczna lub istotna funkcja9 – funkcja, której zakłócenie w sposób istotny wpłynęłoby na wyniki finansowe podmiotu finansowego, na bezpieczeństwo lub ciągłość usług i działalności tego podmiotu lub której zaprzestanie lub wadliwe lub zakończone niepowodzeniem działanie w sposób istotny wpłynęłoby na dalsze wypełnianie przez podmiot finansowy warunków i obowiązków wynikających z udzielonego mu zezwolenia lub jego innych obowiązków wynikających z obowiązujących przepisów dotyczących usług finansowych

Użycie wspomnianych terminów ma istotny wpływ na zakres definicji pojęcia „incydent związany z ICT” oraz „poważny incydent związany z ICT”, a co za tym idzie na zakres obowiązków wynikających z Rozporządzenia DORA, w których pojęcia te są wykorzystywane.

W kontekście definicji incydentu związanego z ICT można wskazać na to, że użycie w nim terminu „bezpieczeństwo sieci i systemów informatycznych” ma kluczowe znaczenie dla zakresu omawianej definicji. W ramach definicji pojęcia bezpieczeństwa sieci i systemów informatycznych odwołano się bowiem do wszelkich zdarzeń, które mogą naruszyć dostępność, autentyczność, integralność lub poufność przechowywanych, przekazywanych lub przetwarzanych danych lub usług oferowanych przez te sieci i systemy informatyczne lub dostępnych za ich pośrednictwem. W związku z użyciem tak szerokiego terminu (wszelkie zdarzenia) można argumentować, że przyczyną incydentów związanych z ICT mogą być nie tylko cyberataki, ale również np. awarie. Wniosek taki potwierdza wprowadzenie w Rozporządzeniu DORA pojęcia „cyberatak”, o węższym zakresie niż „incydent związany z ICT”10, jak również treść motywu 79 dyrektywy NIS2. Wskazano w nim, że „ponieważ zagrożenia bezpieczeństwa sieci i systemów informatycznych mogą mieć różne źródła, środki zarządzania ryzykiem w cyberbezpieczeństwie powinny opierać się na podejściu uwzględniającym wszystkie zagrożenia, mającym na celu ochronę sieci i systemów informatycznych oraz środowiska fizycznego tych systemów przed zdarzeniami takimi jak kradzież, pożar, powódź, awaria telekomunikacyjna bądź awaria zasilania lub nieuprawniony dostęp fizyczny do infrastruktury związanej z informacjami i przetwarzaniem informacji (…)”.

W definicji „poważnego incydentu związanego z ICT” wykorzystano pojęcie „incydent związany z ICT”. Dlatego kwestia omówiona w poprzednim akapicie będzie miała znaczenie również dla poważnych incydentów związanych z ICT. Jednocześnie, zakres pojęcia „poważny incydent związany z ICT” został zawężony w Rozporządzeniu DORA w stosunku do pojęcia „incydent związany z ICT” przez wskazanie na dalej idące skutki jego wystąpienia. Poważnym incydentem związanym z ICT jest więc w świetle Rozporządzenia DORA taki incydent związany z ICT, który ma duży negatywny wpływ na sieci i systemy informatyczne, które wspierają krytyczne lub istotne funkcje podmiotu finansowego. Z jednej więc strony negatywny wpływ poważnego incydentu związanego z ICT na sieci i systemy informatyczne powinien być „duży” (takiej ocenie służyć będą kryteria klasyfikacji, o czym będzie mowa w kolejnej części opracowania). Z drugiej zaś strony poważny incydent związany z ICT powinien mieć wpływ na takie sieci i systemy informatyczne, które wspierają krytyczne lub istotne funkcje podmiotu finansowego (w zakresie ustalania, co należy rozumieć pod pojęciem krytycznych lub istotnych funkcji podmiotu finansowego, duże znaczenie będzie miała przywołana definicja krytycznych lub istotnych funkcji).

Dodatkowo, w Rozporządzeniu DORA zdefiniowano pojęcia istotne z perspektywy przepisów odwołujących się do cyberzagrożeń. Zgodnie z art. 3 pkt 12 Rozporządzenia DORA, przez cyberzagrożenie należy rozumieć „cyberzagrożenie zdefiniowane w art. 2 pkt 8 rozporządzenia (UE) 2019/881”. Uwzględniając odesłanie11, obejmuje to „wszelkie potencjalne okoliczności, zdarzenie lub działanie, które mogą wyrządzić szkodę, spowodować zakłócenia lub w inny sposób niekorzystnie wpłynąć w przypadku sieci i systemów informatycznych, użytkowników takich systemów oraz innych osób”. Zgodnie zaś z art. 2 pkt 13 Rozporządzenia DORA, przez znaczące cyberzagrożenie należy rozumieć „cyberzagrożenie, którego charakterystyka techniczna wskazuje, że potencjalnie może spowodować poważny incydent związany z ICT lub poważny incydent operacyjny lub poważny incydent w zakresie bezpieczeństwa związany z płatnościami”.

W świetle przywołanych definicji podkreślić można przede wszystkim potencjalny charakter zjawisk, które mogą być cyberzagrożeniem, jak i ich szerokie ujęcie (wszelkie potencjalne okoliczności, zdarzenie lub działanie). Ważne jest także to, że definicja znaczącego cyberzagrożenia odwołuje się do zdefiniowanego terminu „cyberzagrożenie”, zaś jego znaczący charakter definiowany jest z perspektywy potencjalnych skutków, tj. możliwości spowodowania przez dane cyberzagrożenie poważnego incydentu związanego z ICT lub poważnego incydentu operacyjnego lub poważnego incydentu w zakresie bezpieczeństwa związanego z płatnościami. Podkreśla to powiązanie definicji znaczącego cyberzagrożenia z poważnymi incydentami.

Przegląd obowiązków Rozporządzenia DORA w obszarze zarządzania incydentami związanymi z ICT

W ramach obowiązków w zakresie incydentów związanych z ICT na podmioty finansowe nałożono obowiązek określania, ustanawiania i wdrażania procesu zarządzania incydentami związanymi z ICT w celu wykrywania incydentów związanych z ICT, zarządzania nimi i ich zgłaszania12.

Dodatkowo, zgodnie z art. 17 ust. 2 Rozporządzenia DORA, na podmiotach finansowych ciąży obowiązek rejestrowania wszystkich incydentów związanych z ICT. Przepis ten przewiduje także obowiązek podmiotów finansowych dotyczący ustanowienia odpowiednich procedur i procesów, które mają zapewnić spójne i zintegrowane monitorowanie incydentów związanych z ICT oraz obsługę takich incydentów, a także działania następcze w związku z takimi incydentami, aby zapewnić zidentyfikowanie, udokumentowanie i wyeliminowanie podstawowych przyczyn. Ma to zapobiec występowaniu takich incydentów.

Rozporządzenie DORA wskazuje na niezbędne elementy procesu zarządzania incydentami związanymi z ICT13 i są nimi:

a) wprowadzenie wskaźników wczesnego ostrzegania;

b) ustanowienie procedur identyfikowania, śledzenia, rejestrowania, kategoryzowania i klasyfikowania incydentów związanych z ICT według ich priorytetu i dotkliwości oraz krytyczności usług, na które incydenty te mają wpływ, zgodnie z kryteriami określonymi w art. 18 ust. 1 Rozporządzenia DORA;

c) przydzielenie ról i obowiązków, które należy wprowadzić w przypadku różnych rodzajów incydentów związanych z ICT i odnośnych scenariuszy;

d) określenie planów działań informacyjnych skierowanych do pracowników, interesariuszy zewnętrznych i mediów zgodnie z art. 14 Rozporządzenia DORA oraz planów powiadamiania klientów, planów dotyczących wewnętrznych procedur eskalacji, w tym skarg klientów związanych z ICT, jak również, w stosownych przypadkach, dostarczania informacji podmiotom finansowym działającym jako kontrahenci;

e) zapewnienie zgłaszania co najmniej poważnych incydentów związanych z ICT właściwej kadrze kierowniczej wyższego szczebla oraz informowanie organu zarządzającego co najmniej o poważnych incydentach związanych z ICT wraz z wyjaśnieniem wpływu, reakcji i dodatkowych kontroli, które należy ustanowić w wyniku takich incydentów związanych z ICT;

f) ustanowienie procedur reagowania na incydenty związane z ICT w celu złagodzenia wpływu i zapewnienia przywrócenia operacyjności i bezpieczeństwa usług w rozsądnym terminie.

Zakres obowiązków dotyczących zarządzania incydentami związanymi z ICT określony jest w rozdziale III Rozporządzenia DORA, o których będzie jeszcze mowa w kolejnej części opracowania. Co istotne, dla realizacji omawianych obowiązków mogą mieć także znaczenie inne przepisy Rozporządzenia DORA. Przykładem mogą tu być:

  1. art. 14 Rozporządzenia DORA14 – przewidziano w nim między innymi obowiązek wprowadzenia przez podmioty finansowe planów działań informacyjnych na wypadek wystąpienia sytuacji kryzysowej, umożliwiających odpowiedzialne ujawnianie, co najmniej, poważnych incydentów związanych z ICT lub podatności klientom i kontrahentom, a także, w przypadkach, opinii publicznej;
  2. art. 10 ust. 1 Rozporządzenia DORA – nałożono nim na podmioty finansowe obowiązek dysponowania mechanizmami pozwalającymi na szybkie wykrywanie nietypowych działań, zgodnie z art. 17 Rozporządzenia DORA, w tym problemów związanych z wydajnością sieci ICT i incydentów związanych z ICT, oraz pozwalającymi na identyfikację potencjalnych istotnych pojedynczych punktów awarii15;
  3. art. 10 ust. 3 Rozporządzenia DORA – wskazano w nim, że podmioty finansowe powinny przeznaczać wystarczające zasoby i zdolności na monitorowanie działalności użytkowników, występowania nieprawidłowości w zakresie ICT oraz incydentów związanych z ICT, a w szczególności cyberataków.
Co ważne, pewne elementy wymogów dotyczących zarządzania ryzykiem związanym z ICT istotne w kontekście incydentów związanych z ICT będą także doprecyzowane w aktach wykonawczych do Rozporządzenia DORA. Przykładowo, w art. 15 lit. c) Rozporządzenia DORA przewidziano podstawę do opracowania przez Europejskie Urzędy Nadzoru16 projektu regulacyjnych standardów technicznych. Ich celem ma być doprecyzowanie elementów określonych w art. 10 ust. 1 Rozporządzenia DORA, które umożliwiają szybkie wykrywanie nietypowych działań oraz kryteriów określonych w art. 10 ust. 2 Rozporządzenia DORA dotyczących uruchamiania procesów wykrywania incydentów związanych z ICT i reagowania na nie.

______________________
1art. 1 ust. 1 lit. a) ppkt (ii) Rozporządzenia DORA
2zgodnie z art. 3 pkt 8 Rozporządzenia DORA
3art. 3 pkt 10 Rozporządzenia DORA
4art. 3 pkt 2 Rozporządzenia DORA
5art. 6 pkt 1 dyrektywy Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa na terytorium Unii, zmieniającej rozporządzenie (UE) nr 910/2014 i dyrektywę (UE) 2018/1972 oraz uchylająca dyrektywę (UE) 2016/1148 („dyrektywa NIS2”)
6Określenie pełnej definicji terminu sieci i systemy informatyczne z Rozporządzenia DORA wymaga przytoczenia również definicji terminu „sieci łączności elektronicznej”. Zgodnie z art. 2 pkt 1 dyrektywy Parlamentu Europejskiego i Rady (UE) 2018/1972 z dnia 11 grudnia 2018 r. ustanawiającej Europejski kodeks łączności elektronicznej, „sieć łączności elektronicznej” oznacza systemy transmisyjne, niezależnie do tego, czy opierają się na stałej infrastrukturze lub scentralizowanym zarządzaniu zasobami, oraz, w stosownych przypadkach, urządzenia przełączające lub routingowe oraz inne zasoby, w tym nieaktywne elementy sieci, które umożliwiają przekazywanie sygnałów przewodowo, za pomocą radia, środków optycznych lub innych rozwiązań wykorzystujących fale, w tym sieci satelitarnych, stacjonarnych (komutowanych i pakietowych, w tym internetu) i sieci ruchomych, elektroenergetycznych systemów kablowych, w zakresie, w jakim są one wykorzystywane do przekazywania sygnałów, w sieciach nadawania radiowego i telewizyjnego oraz sieciach telewizji kablowej, niezależnie od rodzaju przekazywanej informacji
7art. 3 pkt 4 Rozporządzenia DORA
8art. 6 pkt 2 dyrektywy NIS2
9art. 3 pkt 22 Rozporządzenia DORA
10Zgodnie z art. 3 pkt 14 Rozporządzenia DORA „cyberatak” oznacza złośliwy incydent związany z ICT wywołany przez próbę zniszczenia, ujawnienia, zmiany, dezaktywacji, kradzieży lub uzyskania nieuprawnionego dostępu do składnika aktywów lub jego nieuprawnionego wykorzystania przez jakiegokolwiek agresora
11art. 2 pkt 8 rozporządzenia Parlamentu Europejskiego i Rady (UE) 2019/881 z dnia 17 kwietnia 2019 r. w sprawie ENISA (Agencji Unii Europejskiej ds. Cyberbezpieczeństwa) oraz certyfikacji cyberbezpieczeństwa w zakresie technologii informacyjno-komunikacyjnych oraz uchylenia rozporządzenia (UE) nr 526/2013 („Akt o cyberbezpieczeństwie”)
12art. 17 ust. 1 Rozporządzenia DORA
13art. 17 ust. 3 Rozporządzenia DORA
14Do art. 14 Rozporządzenia DORA wprost odnosi się art. 17 ust. 3 lit. d) tego rozporządzenia
15W art. 10 ust. 2 doprecyzowano natomiast, że tego rodzaju mechanizmy wykrywania powinny umożliwiać wielopoziomową kontrolę, określać progi alarmowe i kryteria uruchamiania i inicjowania procesów reagowania na incydenty związane z ICT, łącznie z automatycznymi mechanizmami ostrzegawczymi dla odpowiednich pracowników odpowiedzialnych za reagowanie na incydenty związane z ICT
16Europejski Urząd Nadzoru Bankowego, Europejski Urząd Nadzoru Giełd i Papierów Wartościowych oraz Europejski Urząd Nadzoru Ubezpieczeń i Pracowniczych Programów Emerytalnych

źródło: https://www.knf.gov.pl/dla_rynku/dora/wymagania_dora?articleId=88071&p_id=18

Członkowie ENTRAST udzielają się w środowisku w zakresie cyberbezpieczeństwa

Autorytet w cyberbezpieczeństwie Artur Markiewicz – konsultant, trener – cyberbezpieczeństwo Cyber Security Consultant w Trecom Group – doradztwo w zakresie rozwiązań, konsultacje, inicjator, konsultant i koordynator projektów związanych z bezpieczeństwem. Trener z tematu cyberbezpieczeństwa dla użytkowników, liderów, administratorów.

Rozmawiał jednym ze wspólników ENTRAST-u Michałem Pabichem.

Artur MARKIEWICZ to pomysłodawca, trener, szkoleniowiec, właściciel projektu „cyberkurs.online szkolenia, cyberbezpieczeństwo”.

Mentor pierwszych kroków w IT, kariery i ścieżki rozwoju dla osób wchodzących w IT i już tam obecnych, twórca projektu https://powiedzcospoinformatycznemu.pl sprawdzającego wiedzę #infoSEC;

Członek Zarządu Stowarzyszenia ISSA Polska Stowarzyszenie ds Bezpieczeństwa Systemów Informacyjnych;

  • Lider ds. Projektu Cyfrowy Skaut ISSA Polska, lider projektu Cyfrowy Skaut;
  • Twórca, Lider projektu #ISSAPolskalocal lokalnych społeczności ISSA Polska .local #ISSAPolskalocal;

Członek klubu „POZnaj Toastmasters – wtorek” trener warsztatu z przemówień publicznych, prowadzenia szkoleń, zdawania raportów, prezentacji dla zespołów wewnętrznych. Train the Trainer – Szkolenie podnoszące jakość prelekcji, szkoleń, raportowania i komunikacji w zespole. Warsztat stacjonarny dla osób, które chcą lepiej szkolić, prowadzić prelekcje, komunikować się z zespołem.

SIEM czy SOAR? – porównanie wg ENTRAST

SIEM (Security Information and Event Management) oraz SOAR (Security Orchestration, Automation, and Response) to dwie różne, ale zazwyczaj uzupełniające się technologie stosowane w dziedzinie cyberbezpieczeństwa.

SIEM vs. SOAR: How they Differ and Why they Work Well Together | D3 Security

SIEM (Security Information and Event Management) SOAR (Security Orchestration, Automation, and Response)
SIEM jest platformą, która integruje zbieranie, analizę i prezentację danych dotyczących zdarzeń z systemów informatycznych.

Gromadzi on informacje z różnych źródeł, takich jak logi systemowe, dane zabezpieczeń, komunikaty sieciowe itp.

Analizuje te dane w czasie rzeczywistym, identyfikując potencjalne zagrożenia i zdarzenia bezpieczeństwa.

Umożliwia administracji środowiskiem IT monitorowanie, raportowanie i reagowanie na zidentyfikowane zagrożenia.

 

SOAR to platforma, która integruje narzędzia do zarządzania incydentami, automatyzacji procesów bezpieczeństwa oraz reakcji na incydenty.

Pozwala na opracowanie skomplikowanych workflowów związanych z reakcjami na cyberatak lub incydent bezpieczeństwa.

Automatyzuje zadania, które wcześniej musiały być wykonywane ręcznie, co zwiększa efektywność i szybkość reakcji na incydenty.

Umożliwia zautomatyzowaną odpowiedź na powszechne zagrożenia, co pozwala zespołom bezpieczeństwa skoncentrować się na bardziej złożonych problemach.

Podsumowując, SIEM jest bardziej skoncentrowany na analizie i monitorowaniu danych bezpieczeństwa, podczas gdy SOAR koncentruje się na automatyzacji i orchestrowaniu reakcji na incydenty. W praktyce, organizacje często łączą obie technologie, korzystając z SIEM do monitorowania i identyfikacji zagrożeń, a SOAR do szybkiej i zautomatyzowanej reakcji na te zagrożenia.