Oprogramowanie pod lupą (cz. 5)

Bezpieczeństwo systemów informatycznych rozumiane jest jeszcze bardzo często (również przez niektórych informatyków) w kategoriach pojęć bliższych dziedzinie BHP niż np. kontrwywiadu. Stawiając problem nieco ekstremalnie, można by powiedzieć, że znaczna część użytkowników skłonna jest uznawać za bezpieczny system informatyczny, z którym praca nie grozi porażeniem prądem lub nabawieniem się wady wzroku.

Bezpieczeństwo systemów informatycznych rozumiane jest jeszcze bardzo często (również przez niektórych informatyków) w kategoriach pojęć bliższych dziedzinie BHP niż np. kontrwywiadu. Stawiając problem nieco ekstremalnie, można by powiedzieć, że znaczna część użytkowników skłonna jest uznawać za bezpieczny system informatyczny, z którym praca nie grozi porażeniem prądem lub nabawieniem się wady wzroku.

Być może sytuacja taka wynika z braku polskiego odpowiednika dla pojęcia "security", w którego zakresie semantycznym mieści się również zapewnianie ochrony przed stratami materialnymi. W przypadku systemów informatycznych nie chodzi tu tylko o koszty związane z odzyskaniem utraconych danych i poniesione w konsekwencji przestojów w pracy, ale również o odszkodowania, na jakie narażony jest posiadacz poufnych informacji, który dopuścił do przecieku i naraził w ten sposób na straty, nie tylko siebie, lecz także osoby trzecie.

Bezpieczeństwo (security) systemu to jednym słowem taka technologia pracy, która zawiera z jednej strony rozwiązania chroniące zbiory danych i samo oprogramowanie przed nieodwracalnym uszkodzeniem w wyniku zdarzeń losowych; z drugiej - gwarantuje w pełni selektywny dostęp do informacji (tylko powołanym do ich uzyskiwania), zapewniając równocześnie dostarczenie ich w wymaganym terminie.

Systemy bezpieczeństwa z kolei to odpowiednio zorganizowane siły, środki i urządzenia techniczne, wykorzystywane w tak zdefiniowanym celu.

Konieczna wydaje się tu jeszcze jedna uwaga natury generalnej: system bezpieczeństwa możemy porównać do łańcucha. Z tego punktu widzenia spolegliwość systemów informatycznych odpowiada spolegliwości, jaką zapewnia najsłabsze jego ogniwo.

Zgodnie z charakterem naszego cyklu omówimy tylko jeden element tego łańcucha.

Los nie wybiera

Oceniając oprogramowanie lub formułując założenia tej oceny należy kierować się zasadą: "jeśli coś może funkcjonowć źle - to będzie". Kupujący software musi zatem brać pod uwagę nie "przeciętne warunki" jego eksploatacji, lecz krańcowe: np. przeciążenie systemu, obsługę przez najsłabszych pracowników, zaniki zasilania, awarie sprzętu, itd. Bez przesady i panikowania, należy jednak koniecznie odpowiedzieć na pytanie: czy software'owe i inne procedury bezpieczeństwa technologicznego (które powinny być opisane w dostarczanej dokumentacji) są w stanie ochronić system w przypadku wydarzeń losowych, nawet jeśli ich prawdopodobieństwo jest pozornie niewielkie.

W pierwszej kolejności musimy więc dokonać analizy potencjalnych zagrożeń i wynikających z nich ewentualnych skutków. Poprawna "symulacja" często potrafi przekonać najbardziej zatwardziałego dusigrosza o konieczności zakupu lepiej "oprzyrządowanego" choć droższego systemu.

Kolejny element weryfikacji stanowi ocena kompleksowości rozwiązań. Sprawdzić należy, czy w środowisku eksploatacyjnym istnieją procedury zabezpieczające i czy oprogramowanie jest przygotowane do skutecznej i spójnej z nimi współpracy.

Z kolei należy poddać ocenie konkretne rozwiązania technologiczne obejmujące m.in.: - monitorowanie (dziennik) procesu przetwarzania;

  • odporność na błędy obsługi;

  • odporność na awarie sprzętu (sygnalizacja i blokowanie błędów);

  • stopień zabezpieczenia przed utratą zbiorów;

  • niezawodność i stopień automatyzacji procedur składowania;

  • poprawność i kompletność opisu dokumentacyjnego procedur zabezpieczających w tym także dot. organizacji przetwarzania.

    Ostatnim ocenianym elementem jest procedura awaryjnego przetwarzania danych i jej efektywność. (W krajowych systemach raczej jej nie znajdziemy.)

    Jak widać wymagających sprawdzenia elementów, zapewniających bezpieczeństwo danych jest niemało, co sprawia, że ten fragment procesu weryfikacji oprogramowania może okazać się kosztowny. Do problemu należy więc podchodzić zgodnie z teorią gier. Tu - jak pamiętamy - im prawdopodobieństwo wygranej mniejsze, tym wygrana wyższa. W przypadku zabezpieczania systemów komputerowych należy pamiętać, że im mniejsze prawdopodobieństwo określonego rodzaju awarii, tym bardziej katastrofalne jej skutki.

    Nie przypadkiem więc i nie z powodu nadmiaru pieniędzy, duże firmy utrzymują z reguły w znacznie oddalonym miejscu (ponieważ uwzględniają także powodzie i trzęsienia ziemi) dokładne kopie nie tylko programów, ale niekiedy całych systemów informatycznych. Możemy sobie wyobrazić, ile to kosztuje. Żadna jednak z takich firm nie pochwaliła się dotąd, ile kosztowała ją nawet czasowa utrata możliwości korzystania z systemu. Kilkanaście lat temu szef jednej z dużych firm software'owych na pytanie: czy i kiedy uruchomiłby pracę gdyby jego ośrodek spłonął doszczętnie, odpowiedział: "po 3 godzinach, bo tyle trwa przelot do naszej filii".

    Tymczasem w Polsce kopie zapasowe trzyma się w sejfie starego typu (brak ochrony przed pożarem, zalaniem wodą itd.) albo wręcz w szufladzie biurka, często w tym samym pomieszczeniu, co komputer ze składowanym dyskiem.

    Computer security

    Oprogramowanie, a dokładniej jego procedury, które mają strzec tajemnicy firmy, same także powinny być tajne i chronione. Produkt taki musi powstać w warunkach specjalnych, gwarantujących poufność procesu projektowania i wdrażania. Nie każdy wykonawca może to zapewnić. W tym kontekście, np. ogłoszenie przez użytkownika przetargu na budowę systemu zabezpieczeń software'owych jest rozwiązaniem uderzającym w poufność przedsięwzięcia.

    Kolejny obszar nieporozumień to fragmentarycznie i nieobiektywnie przeprowadzona analiza potencjalnych skutków nieuprawnionego dostępu dla systemu informacyjnego lub całej firmy. Typowym tego przykładem może być zastosowanie w firmie obracającej chemikaliami (w tym truciznami) oprogramowania, którego procedury zabezpieczająco-kontrolne nie różnią się od procedur software'u do obsługi sklepu z odzieżą. Mimo więc, że stosowanie standardowych procedur zabezpieczających jest konieczne, a ponadto obniża koszty, nie może być rozwiązaniem typowym, powielanym. Zastosowanie identycznych rozwiązań w podobnych firmach zwiększa prawdopodobieństwo i opłacalność prób ich przełamania.

    Na zakończenie warto przypomnieć stare powiedzenie: "nie ma takiego zamka, którego nie można otworzyć". Potrzeba tylko czasu. Dlatego system bezpieczeństwa powinien być aktywny, tzn. reagować na każdy sygnał czy ślad zagrożenia, ubezpieczać samego siebie.