Rozmowa z Piotrem Borkowskim, Senior System Engineerem w Veracompie
Jakie rozwiązania należy zaliczyć do infrastruktury krytycznej w przedsiębiorstwie? Czy są one definiowane przez charakterystykę danego systemu, np. jego skalowalność, moc obliczeniową lub funkcjonalność? Czy też raczej powinna być to klasyfikacja biznesowa, a więc obejmująca wszystko, co jest ważne z perspektywy przedsiębiorcy?
Zdecydowanie należy przyjąć kryterium bazujące na ocenie, co mogłoby się wydarzyć, gdyby dane rozwiązanie przestało działać. Warto także podkreślić, że hasło „infrastruktura krytyczna” pochodzi z sektora rządowego, gdzie w ten sposób nazywane są obszary kluczowe dla bezpieczeństwa fizycznego i gospodarczego kraju. Zostało ono zaadaptowane na potrzeby branży IT, a w niej bardziej precyzyjnym określeniem raczej jest ciągłość biznesowa, która powinna być opisana w firmowej polityce bezpieczeństwa. To właśnie w tym dokumencie należy określić, co w danym przedsiębiorstwie wiąże się z bezpieczeństwem informacji, ale także procesy biznesowe, bo na przykład w fabryce jednym z najważniejszych systemów są linie produkcyjne. Zadaniem polityki bezpieczeństwa jest także zdefiniowanie tego, jakie grupy osób mają dostęp do informacji, na jakiego typu urządzeniach one się znajdują, w jaki sposób są przesyłane itd. Siłą rzeczy więc w każdej firmie będzie to co innego.
Niemniej, tego typu decyzje powinny być podejmowane na szczeblu zarządu?
To zależy od tego, jak firma jest zorganizowana, natomiast oczywiście zarząd powinien wiedzieć, w jaki sposób zabezpieczane są dane, zresztą z niektórymi elementami tej strategii powinni być zaznajomieni także pracownicy. Natomiast za jej stworzenie mogą być odpowiedzialne różne osoby, z reguły są to pracownicy działu IT, czasem przy współpracy z osobami z innych działów. Do konsultacji można też zatrudnić zewnętrznego audytora.
Czy dokument polityki bezpieczeństwa powinien obejmować wyłącznie rozwiązania i procesy kluczowe dla funkcjonowania przedsiębiorstwa, czy też należy poświęcić im osobny rozdział, a całość powinna dotyczyć znacznie szerszego obszaru?
Bezpieczeństwo firmy powinno być postrzegane bardzo szeroko, ponieważ zależy od wielu elementów. Naruszenie bezpieczeństwa drobnego i pozornie niewiele znaczącego elementu może stać się przyczynkiem do unieruchomienia pracy elementu krytycznego, a więc wpłynięcia na ciągłość biznesową przedsiębiorstwa. Szczególnie ważne jest zwracanie uwagi na zachowanie użytkowników, bo to oni tradycyjnie są najsłabszym ogniwem i mogą doprowadzić do ujawnienia wrażliwych informacji. Dlatego dobrze stworzona polityka bezpieczeństwa powinna uwzględniać także procedury szkolenia pracowników firmy i uświadamiania ich o tym, jak mały incydent może przerodzić się w naprawdę duży problem. Poza tym polityka bezpieczeństwa powinna dotyczyć nie tylko kwestii związanych z IT, czyli cyberochroną, ale także backupów danych, bezpieczeństwa fizycznego, przeciwpożarowego itd.
Czy stworzony w ten sposób dokument powinien opisywać w jaki sposób poszczególne obszary należy zabezpieczyć, czy też tylko wskazywać finalny efekt do uzyskania w wyniku zabezpieczenia?
Polityka bezpieczeństwa to opis strategii, więc przedstawianie taktyki oraz konkretnych zadań do wykonania nie powinno w nim mieć miejsca. Natomiast nic nie stoi na przeszkodzie, aby opracować dodatkową dokumentację wykonawczą, powdrożeniową, instrukcje obsługi, postępowania itd. ale sama polityka bezpieczeństwa nie powinna ulegać zbyt częstym modyfikacjom.
Czy wdrażanie rozwiązań ochronnych zawsze musi być pochodną zapisów polityki bezpieczeństwa? Czy można dopuścić do sytuacji, że najpierw wdrażane jest jakieś rozwiązanie, a dopiero potem informacja o danym sposobie ochrony pojawia się w dokumencie?
W firmie o wysokiej kulturze technicznej nie powinno się tak zdarzyć, szczególnie jeśli efekt wdrożenia danego rozwiązania znacznie odbiega od kształtu przyjętej wcześniej strategii ochronnej. Ale oczywiście można też przyjąć założenie, że w firmie wzięto się za opracowywanie polityki bezpieczeństwa już po dokonanych wcześniej wdrożeniach. Zawsze jednak po wygenerowaniu takiego dokumentu lub jego aktualizacji należy sprawdzić czy polityki w urządzeniach są zgodne z przyjętymi regułami.
Czy polityka bezpieczeństwa powinna określać za pomocą jakiej kategorii narzędzi należy zapewnić ochronę zgodnie z przyjętymi regułami – sprzętu, oprogramowania, usług itd.?
W wyjątkowych przypadkach tak, ale przyjmowanie takiego podziału „na sztywno” bardzo szybko może odebrać elastyczność w działaniu i reagowaniu na ewentualne problemy. Poza tym finalnie zawsze chodzi o bezpieczeństwo informacji lub procesów biznesowych – z tej perspektywy nie ma znaczenia, czy np. dany firewall jest wdrożony jako sprzęt czy maszyna wirtualna. Najważniejsze jest to, jak został skonfigurowany.
Czy do realizacji zapisów polityki bezpieczeństwa powinna być wyznaczona konkretna osoba, czy też można założyć, że jest to w zakresie normalnych obowiązków działu IT?
Byłoby świetnie, gdyby w firmie została wyznaczona taka osoba, aby z jednej strony koordynować i na bieżąco weryfikować zgodność firmowych procedur oraz konfiguracji rozwiązań IT z zapisami polityki bezpieczeństwa, a z drugiej być pierwszym punktem kontaktu w sytuacjach krytycznych. W przedsiębiorstwach, które mają dział bezpieczeństwa, to on z reguły odpowiada za takie działania. A tam, gdzie go nie ma, najczęściej odpowiedzialność spada na dział IT, bo w kontekście bezpieczeństwa to właśnie narzędzia teleinformatyczne mają do odegrania największą rolę.
Czy za tego typu koordynację ewentualnie można uczynić odpowiedzialnymi firmy trzecie w modelu outsourcingowym, np. integratorów współpracujących z danym klientem?
Odpowiedzialność za realizację polityki bezpieczeństwa raczej powinna być egzekwowana lokalnie. Natomiast od strony technicznej można wyobrazić sobie, że kontrolę nad procesami zapewniającymi bezpieczeństwo infrastruktury IT sprawują zewnętrzne instytucje typu Security Operations Center (SOC). Ale tu pojawia się kwestia zaufania, związanego np. z tym, że taki podmiot może cedować część obowiązków na kolejne, współpracujące z nim i finalnie odpowiedzialność się rozmywa. Dlatego w instytucjach krytycznych dla bezpieczeństwa kraju – bankach, elektrowniach itp. – takie działy organizowane są w strukturze wewnętrznej. Nie widzę też trendu, aby integratorzy angażowali się w budowę SOC-ów. Do pracy tego typu jednostki trzeba wykwalifikowanych ekspertów, którzy muszą poświęcić się jej bez reszty. Tymczasem integratorzy potrzebują specjalistów, którzy będą zaangażowani podczas prac wdrożeniowych u coraz to nowszych klientów. Powstaje więc konflikt interesów, szczególnie, że ekspertów na rynku brakuje.
Ale w związku z tym na polskim rynku powinno szybko rosnąć zapotrzebowanie na tego typu usługi?
Absolutnie tak, można to zauważyć szczególnie w kontekście RODO, które nałożyło obowiązek ciągłego monitorowania incydentów. Jeżeli firma nie ma własnego działu bezpieczeństwa, to może to zlecić właśnie w SOC-u. Problem jedynie w tym, że jest to na razie dość droga usługa i czasami taniej będzie wykształcić własnego specjalistę ds. bezpieczeństwa i dobrze go wynagradzać. Być może wkrótce wzrośnie zapotrzebowanie na tego typu placówki, specjalizujące się w obsłudze średnich przedsiębiorstw?
Co w polskich firmach jest obecnie największą przeszkodą w zapewnieniu bezpieczeństwa na odpowiednio wysokim poziomie?
Wiele wdrożeń realizowanych jest punktowo, nie są częścią spójnego planu, ale zostały przeprowadzone, bo pojawiły się pieniądze na konkretny projekt. Dobra strategia, „oddzielona” od decyzji personalnych, na pewno pomogłaby to zmienić. To właśnie jest celem implementacji w firmach dokumentu polityki bezpieczeństwa. Zaś naszą – dystrybutora i integratorów – rolą jest budowanie świadomości dotyczącej tego, jak można przy pomocy konkretnych rozwiązań zapewnić maksymalną ochronę danych i procesów w firmie.
