Certyfikacja
W ostatnim czasie głośno mówi się o certyfikacji produktów na rynku ochrony. Przykładem jest artykuł w Zabezpieczeniach nr 2/2006. Nic w tym jednak dziwnego, w końcu jakość, którą gwarantują, lub przynajmniej powinny gwarantować certyfikaty, jest najważniejszym czynnikiem doboru urządzeń zabezpieczających. Istotne jest to zarówno dla zabezpieczeń mechanicznych, elektronicznych, jak i systemów związanych z monitoringiem. Właśnie to ostatnie zagadnienie wymaga pewnego rozwinięcia w świetle szybkiego rozwoju techniki i autentycznej inwazji technologii informatycznych na branżę ochrony. Mam nadzieję, że poniżej uda mi się przystępnie przedstawić podstawowe zagadnienia związane z certyfikacją oprogramowania dla rynku ochrony.
Wszyscy zdążyliśmy się przyzwyczaić do tego, że do ochrony strategicznych obiektów należy wybrać centralę alarmową mająca klasę bezpieczeństwa „S”. Sygnały o zdarzeniach powinny trafiać do centrów monitoringu co najmniej dwoma kanałami transmisji, również spełniającymi rygorystyczne wymogi niezawodności i czasu transmisji. Tam powinny być odbierane przez stacje bazowe mające stosowne certyfikaty. Stacje bazowe zaś powinny buforować sygnały i przesyłać je do specjalnie wyznaczonych komputerów. I tu właśnie kończy się świadomość potrzeby zapewnienia bezpieczeństwa. Co więc z tego, że źródło sygnałów i cały tor transmisji są wyjątkowo pewne i wysokiej jakości, jeżeli ostatnie ogniwo nie gwarantuje nam bezbłędnego działania. Truizmem jest twierdzenie, że cały system wart jest tyle, ile najsłabsze ogniwo, doskonale jednak oddaje przedstawioną sytuację. Ogniwem tym w naszym przypadku jest oprogramowanie, istotą problemu – specyfika wytwarzania i złożoność. Użytkownicy często nie zdają sobie sprawy z roli oprogramowania. Przykładowo jeden z popularniejszych systemów radiowych w naszym kraju praktycznie nie buforuje sygnałów, lecz na bieżąco przesyła je do komputera. Wystarczy więc chwilowa przerwa w pracy programu i już tracimy aktualny stan monitorowanych obiektów.
Przyczyny
Wydaje się więc, że wszystkie przesłanki skłaniają nas do unormowania powyższej sytuacji. Tak się jednak nie dzieje. Możemy nakreślić trzy podstawowe przyczyny owego stanu rzeczy. Pierwszym powodem jest brak lobbingu producentów oprogramowania. Podyktowane jest to często strachem przed koniecznością wykazania jakości swoich produktów. Jest to zrozumiałe ze względu na skomplikowanie zagadnienia i praktyczną niemożliwość stworzenia programu pozbawionego błędów. Nikt więc nie porusza tego zagadnienia, a skoro klienci nie domagają się certyfikatów jakości, to nikt o nie zabiega. Drugą przyczyną jest brak ekspertów na rynku ochrony, którzy mogliby oceniać produkty. Nie powinni to być zwykli informatycy spoza branży ze względu na brak znajomości specyfiki wymagań stawianych przed oprogramowaniem do monitoringu. Z drugiej strony, wśród ludzi zajmujących się zawodowo systemami informatycznymi dla agencji ochrony ciężko znaleźć osoby postronne, które nie są związane z producentami. Ostatnią kwestią jest brak wytycznych dotyczących przyznawania certyfikatów. Jedyną szansą jest powołanie grupy, w skład której wchodziliby wszyscy zainteresowani producenci. Grupa ta miałaby określić normy dla oprogramowania. Równocześnie mieszane grono ekspertów gwarantowałoby wysoką bezstronność. Później zaś, korzystając z przygotowanych wytycznych, poddawano by badaniu programy. Brak dyskusji na ten temat powoduje niską świadomość klientów i co za tym idzie, brak nacisków na producentów oprogramowania. System informatyczny jest nadal traktowany tylko jako dodatek do stacji bazowej, pomimo, jego faktycznie dużego znaczenia.
Podział
W niniejszym tekście zarysowany zostanie z grubsza zakres zagadnień, które należałoby wziąć pod uwagę w trakcie przygotowywania norm jakościowych dla oprogramowania. Trudno jednak ustalić szczegółowe warunki, które musiałby spełniać program niezależnie od swojego przeznaczenia. W pierwszej kolejności trzeba dokonać podziału. Można wyróżnić następujące kategorie:
- monitoring napadów i włamań w obiektach stałych,
- monitoring obiektów ruchomych,
- monitoring środowiska,
- monitoring CCTV,
- kontrola dostępu i rejestracja czasu pracy,
- weryfikacja pracy agentów ochrony.
Niestety, nie jest już tak łatwo przyporządkować program do jednej z grup, tak jak to było możliwe jeszcze kilka lat temu, ponieważ w dzisiejszych czasach integracja obejmuje nie tylko różne stacje bazowe, ale i różne typy monitoringu. Przykładami mogą być:
- program ochrony firmy Ad Info (monitoring obiektów stałych i CCTV);
- program Kronos NET firmy NEXT! (monitoring obiektów stałych, środowiska, CCTV, agentów ochrony, a także w pewnym stopniu obiektów ruchomych i kontroli dostępu);
- program ESOMWIN 2000 firmy EcoTrade (monitoring obiektów stałych i ruchomych).
Kategoryzować programy można także pod względem obszaru, jaki obejmują swoim działaniem. Wpływa to w sposób zasadniczy na zakres i szczegółowość przechowywanych danych, oraz stawia wymogi dotyczące maksymalnego obciążenia systemu. Wyróżniamy programy:
- lokalne do tzw. inteligentnych budynków,
- rozległe, czyli systemy zbierające sygnały z dużych obszarów, np.: SIMS.
Mając już przygotowaną propozycję klasyfikacji, możemy określić dla każdej z grup zakres wymaganych cech.
Badanie jakości
Tak jak w przypadku pozostałych rozwiązań na rynku ochrony, certyfikaty przyznawane oprogramowaniu muszą uwzględniać kilka klas jakości. Każda z klas powinna zawierać zestaw cech, które przynajmniej w minimalnym stopniu spełnia program. Najistotniejszych wydaje się pięć czynników oceny.
Bezpieczeństwo
W dobie globalnej pajęczyny, zdalnego dostępu do systemów, aplikacji rozproszonych zwykłe hasło chroniące dane przestaje gwarantować jakikolwiek stopień zabezpieczenia. Opieranie się na popularnych platformach komunikacji, których wady są powszechnie znane i wykorzystywane przez włamywaczy, nie może być uznane za bezpieczne. Nowoczesne aplikacje nie mogą być zbudowane na podstawie dwuwarstwowej architektury, gdzie baza danych jest wystawiona do sieci zewnętrznej, czy też wykorzystywać IIS lub inny popularny serwer stron WWW. Bezpieczeństwo to także ochrona danych w trakcie obróbki. Program nigdy nie powinien przechowywać istotnych informacji tylko w pamięci ulotnej. W przypadku nagłego restartu czy też usterki wszystkie dane muszą być zachowane. Należy więc przygotować zestaw warunków, których spełnienie będzie gwarancją bezpieczeństwa. Rzetelna ocena może być jednak trudna, bo wymagałaby audytu kodu i kontroli zastosowanych technologii. Jest to proces niezwykle pracochłonny, kosztowny i rodzący obawy co do stopnia, w jakim zabezpieczona byłaby tajemnica producenta. Jest to więc delikatna kwestia, którą należy dokładnie rozpatrzeć. Wydaje się jednak, że powinno się raczej polegać na deklaracjach autorów oprogramowania.
Stabilność
Awaria programu finansowego i przestój w pracy działu księgowego przynosi wymierne straty, ale nie jest tragedią. Usterka programu do monitoringu to często zagrożenie mienia, a nawet życia osób zależnych od jego prawidłowego funkcjonowania. Nawet krótki czas przestoju jest dużym problemem. Dodatkowym utrudnieniem jest takie napisanie aplikacji, aby zapewnić jej ciągłą i nieprzerwaną wielomiesięczną pracę. Wycieki pamięci, niewłaściwe bazowanie na czasie systemowym może skutkować cyklicznymi restartami komputera. Trudnością jest też zapewnienie kontroli pracy aplikacji jako całości, jeżeli składa się ona z wielu niezależnych i rozproszonych modułów. Kłopotliwe jest w trakcie procesu certyfikacji dokładne sprawdzenie stabilności, ponieważ wymagałoby to wielomiesięcznych testów. Badanie musi opierać się więc nie tylko na testach laboratoryjnych, ale także potwierdzonych wynikach pracy programu w rzeczywistych warunkach przez zadany czas. Długość okresu podlegającego kontroli powinna zależeć od klasy certyfikatu, o jaki ubiega się producent dla swojego programu.
Funkcjonalność
O przydatności programu do określonego zastosowania decyduje zestaw funkcjonalności i opcji, które oferuje. Zależą one od zastosowań programu. Inne opcje potrzebne są w programie do kontroli dostępu, a inne w aplikacji do monitoringu obiektów ruchomych. Analogicznie przed programem o charakterze lokalnym stawiane są inne wymagania niż przed aplikacją rozległą. Dlatego też przed rozpoczęciem oceny wymagane jest uprzednie wprowadzenie podziału programów na określone grupy zastosowań. Dopiero po przyporządkowaniu aplikacji do grupy można przystąpić do jej oceny. Tutaj, tak jak w przypadku poprzedniego podpunktu, zestaw wymaganych funkcjonalności powinien zależeć od klasy uzyskiwanego certyfikatu.
Ergonomia
To trudne zagadnienie. Wymaga pogodzenia dwóch teoretycznie sprzecznych interesów, a do tego wykorzystuje w pewnej części subiektywne odczucia i przyzwyczajenia użytkowników. Z jednej strony, oczywiste jest, że istotne opcje powinny być łatwo dostępne. Z drugiej jednak strony, nie można ulec pokusie umieszczenia wszystkich funkcji na jednym ekranie. Wywołuje to jedynie wrażenie chaosu i zmusza do stosowania wysokich rozdzielczości. Należy pamiętać o użytkownikach, którzy będą pracować z programem przez wiele godzin, wpatrując się nieprzerwanie w ekran. Dla nich wszystko musi być czytelne, łatwo dostępne, opcje logicznie pogrupowane, a czcionki odpowiednio duże. W trakcie dokonywania oceny będą wymagane nie tylko doświadczenie informatyczne, ale i wiedza o pracy dyspozytora, a tę można nabyć tylko i wyłącznie pracując wcześniej w stacji monitorowania alarmów. Ujęcie tego zagadnienia w normy niezbędne do certyfikacji będzie zadaniem niezwykle trudnym.
Wydajność
Ostatnią, ale nie najmniej ważną cechą jest wydajność, rozumiana jako gotowość programu do przyjęcia zadanej liczby nadchodzących sygnałów przy zapewnieniu kompletnej ich obsługi. Zależy ona jednak nie tylko od zastosowanych rozwiązań i algorytmów, ale także od sprzętu, na którym dany program działa. Rzetelność oceny nie powinna więc zależeć od czynników, na które programiści nie mieli wpływu. Ocena musi uwzględniać platformę, na której działa aplikacja, i uniezależniać od niej wyniki. Obecna sytuacja nie jest najlepsza, chodź pojawiają się już pierwsze oznaki jej zmian. Jako jedną z nich można potraktować przyznanie przez Techom czwartej klasy bezpieczeństwa sieci monitorującej Kronos NET. Wzrost oczekiwań odbiorców świadomie poszukiwanie przez nich bezpiecznych i wygodnych systemów informatycznych jest tylko kwestią czasu. Tym samym będą oni naciskać na producentów, by ci poddali swe produkty procesowi certyfikacji. Mam nadzieję, że artykuł ten stanie się przyczynkiem do rozpoczęcia debaty i ostatecznego uregulowania certyfikacji oprogramowania na rynku ochrony.
Bartłomiej Dryja
Next!
Zabezpieczenia 4/2006