Akwizycja i modernizacja systemu

System Zarządzania Bezpieczeństwem Informacji
od dobrych praktyk do certyfikacji ISO/IEC 27001
Akwizycja systemu lub jego elementów
Jeśli Organizacja ustanawia (lub ustanowiła) SZBI to rozbudowa lub modernizacja systemu
informacyjnego, wprowadzanie nowych funkcjonalności oraz utrzymywanie systemu musi brać pod
uwagę wymagania określone przez SZBI.
Procedury związane z akwizycją systemu lub jego elementów powinny być realizowane z
zachowaniem następujących etapów:
•
Zdefiniowanie potrzeb
Potrzeby powinny wynikać z konieczności realizacji konkretnych procesów biznesowych –
np. instalacja dodatkowego stanowiska dla handlowca, zwiększenie wydajności serwera
bazy danych itp.
Organizacja powinna określić procedury związane ze zgłaszaniem i weryfikacją potrzeb.
•
Zastosowanie podziału na moduły oraz określenie sposoby zarządzania zmianami
Zestawienie modułów powinno obejmować zarówno składniki sprzętowe, jak i
oprogramowanie i urządzenia sieciowe niezbędne do zaspokojenia zgłoszonych i
zaakceptowanych potrzeb.
•
Zdefiniowanie kluczowych interfejsów
Opis zastosowanych interfejsów powinien być kompletny i wyczerpujący.
•
Wybór standardów komunikacyjnych
Należy preferować wykorzystywanie standardów otwartych, których wykorzytywanie nie
wiąże się z ponoszeniem dodatkowych kosztów. Jeśli jest to niemożliwe należy sporządzić
pełną dokumentację opisującą precyzyjnie sposób komunikacji pomiędzy modułami oraz z
resztą systemu.
•
Przeanalizować dostępność i właściwości techniczne dostępnych rozwiązań.
Bardzo ważną rzeczą jest szczegółowe, zgodne z zaleceniami SZBI udokumentowanie całego
procesu przygotowania do zakupu. Jest to szczególnie ważne dla Organizacji, które podlegają
Ustawie o Zamówieniach Publicznych. Staranne i obiektywne przeprowadzenie przygotowania do
akwizycji systemu gwarantuje poprawność przygotowywanej dokumentacji przetargowej, która
powinna uwzględniać wymagania wynikające z utrzymywania SZBI w Organizacji zarówno w
trakcie procesu akwizycji lub modernizacji systemu, jak i po jego przekazaniu do eksploatacji.
Rozdział 9: Akwizycja, rozwój i utrzymanie systemu
(C) Tomasz Barbaszewski
Materiał szkoleniowy
str. 1 z 5
System Zarządzania Bezpieczeństwem Informacji
od dobrych praktyk do certyfikacji ISO/IEC 27001
Kontrola danych wprowadzanych do systemu
Wprowadzanie danych do systemu powinno bezwarunkowo podlegać kontroli. Koniecznie
należy przestrzegać zasady, że każda informacja powinna posiadać określona właściciela, który jest
odpowiedzialny z jej wprowadzenie do systemu i wynikłe z tego tytułu skutki.
Informacja może być wprowadzona do systemu po spełnieniu następujących warunków:
•
•
•
•
użytkownik, który zamierza wprowadzić informację musi zostać poprawnie
uwierzytelniony,
użytkownik, który zamierza wprowadzić informację musi dysponować wymaganymi
uprawnieniami. Wprowadzenie informacji może się wiązać z potwierdzeniem posiadania
tych uprawnień w procesie autoryzacji transakcji,
informacja w postaci elektronicznej (pliku z danymi) przed wprowadzeniem do systemu
powinna być sprawdzona przez odpowiednie oprogramowania pod kątem zawartości
złośliwego oprogramowania,
Organizacja określa wymagania co do stosowanych mechanizmów sprawdzania
integralności oraz ewentualnego poziomu poufności wprowadzanej informacji. Wymagania
te powinny odpowiadać przyjętej Polityce kwalifikowania informacji.
SZBI odpowiadające wymaganiom norm PN-ISO/IEC 27001 i PN-ISO/IEC 177799 wymagają
zarządzania dostępnością, integralnością oraz poufnością informacji. Użytkownik uprawniony do
wprowadzania danych do systemu powinien być zaznajomiony z Polityką kwalifikowania
informacji oraz Polityką kontroli dostępu. W zależności od zakwalifikowania wprowadzanych
danych należy przewidzieć wykorzystywanie mechanizmów gwarantujących kontrolę integralności
informacji oraz ich poufność za pomocą mechanizmów kryptograficznych.
Należy zwrócić uwagę, że sam fakt uwierzytelnienia użytkownika, który wprowadził informację
w żadnym przypadku nie gwarantuje kontroli ich integralności.
Kontrola przetwarzania danych w systemie informatycznym
Zarówno systemy operacyjne, jak i oprogramowanie narzędziowe i użytkowe pozostają pod
stałym nadzorem działu IT. Wszelkie zmiany w oprogramowaniu mogą być realizowane jedynie
przez osoby posiadające odpowiednie upoważnienie i muszą być bezwarunkowo odnotowane w
dziennikach pracy systemu.
Integralność oprogramowania systemowego i użytkowego powinna być okresowo kontrolowana
zgodnie z procedurami dostarczonymi przez dostawcę/producenta. Wraz z oprogramowaniem
powinien być dostarczony zestaw danych testowych oraz warunki uzyskiwania wsparcia
technicznego.
Wszelkie instalacje próbne, testy nowych właściwości i wersji muszą się odbywać poza
systemem produkcyjnym.
Rozdział 9: Akwizycja, rozwój i utrzymanie systemu
(C) Tomasz Barbaszewski
Materiał szkoleniowy
str. 2 z 5
System Zarządzania Bezpieczeństwem Informacji
od dobrych praktyk do certyfikacji ISO/IEC 27001
Zabezpieczenia kryptograficzne
Organizacja powinna określić Politykę zabezpieczeń kryptograficznych lub zaznaczyć, że
odstępuje od ich stosowania. Polityka zabezpieczeń kryptograficznych powinna obejmować:
•
•
•
•
•
ogólny opis stosowanych zabezpieczeń, celu ich wprowadzenia oraz wykorzystywanych
mechanizmów,
realizację kryptograficznej kontroli integralności informacji (funkcje skrótu
kryptograficznego, kody uwierzytelniające wiadomości (MAC), podpisy i certyfikaty
cyfrowe,
wykorzystywane zabezpieczenia kryptograficzne transmisji sieciowych,
wykorzystywanie kryptografii w celu zabezpieczenia poufności danych,
zarządzania mechanizmami kryptograficznymi – w tym zarządzania kluczami.
Kontrola eksploatowanego oprogramowania
Oprogramowanie eksploatowane przez Organizację podlega kontroli działu IT oraz osób
odpowiedzialnych za zarządzanie bezpieczeństwem informacji. Instalacja, konfigurowanie oraz
wszelkie czynności związane z obsługą oprogramowania (również na stanowiskach użytkowników)
mogą być realizowane jedynie przez upoważnionych pracowników. Pracownicy upoważnieni do
instalowania oprogramowania powinni podpisać zobowiązanie do bezwzględnego przestrzegania
prawa o ochronie własności intelektualnej.
Organizacja powinna prowadzić rejestr praw do wykorzystywania oprogramowania (tzw.
Licencji) z podziałem na stanowiska komputerowe i serwery oraz rejestr odpowiednich
dokumentów licencyjnych (dotyczy to również oprogramowania licencjonowanego neiodpłatnie –
np. objętego licencją GPL). Rejestr należy prowadzić w taki sposób, aby mógł on stanowić
wiarygodny dowód legalności wykorzystywanego oprogramowania w przypadku kontroli.
Obowiązki działu IT związane z eksploatacją oprogramowania powinny być przyjęte w sposób
formalny poprzez akceptację zestawu odpowiednich procedur. Do każdego programu powinny być
dostępne dane umożliwiające identyfikację wersji, historię wprowadzonych zmian (instalacja
uzupełnień, łatek itp.), listę uwag zgłaszanych przez użytkowników oraz akcji, które w związku z
nimi podjęto, poziom wsparcia technicznego oraz kontakty z nim związane a także procedurę
testowania poprawności pracy oprogramowania wraz z zestawem danych testowych.
Zarządzanie zmianami oprogramowania
Wszelkie zmiany w oprogramowaniu przed ich wprowadzeniem do systemu produkcyjnego
powinny być sprawdzone w systemie testowym. Po wprowadzeniu zmian w jednym z modułów
systemu należy przeprowadzić testy poprawności jego współpracy z innymi modułami.
Jeśli wprowadzane zmiany mają (lub mogą mieć) wpływ na zmianę zagrożeń i podatności należy
przeprowadzić analizę ryzyka w obszarze planowanych zmian.
Rozdział 9: Akwizycja, rozwój i utrzymanie systemu
(C) Tomasz Barbaszewski
Materiał szkoleniowy
str. 3 z 5
System Zarządzania Bezpieczeństwem Informacji
od dobrych praktyk do certyfikacji ISO/IEC 27001
Rodzaje wykorzystywanego oprogramowania
Obecna praktyka wyróżnia następujące rodzaje oprogramowania:
1. oprogramowanie dostępne komercyjnie „z półki”,
2. Wolne i Otwarte Oprogramowanie (różne licencje),
3. oprogramowanie opracowywane (lub modyfikowane) na indywidulane zamówienie.
Oprogramowanie wymienione w pozycjach 1 i 2 jest najczęściej wykorzystywane na podstawie
tak zwanej „licencji” (prawa do używania - „Right to Use”). Nie obejmuje ona przeniesienia praw
autorskich na Organizację, a jedynie umowę stwierdzającą, że Organizacja posiada prawo do
odpłatnego (poz.1) lub nieodpłatnego (poz.2) korzystania z oprogramowania na warunkach
zawartych w dokumencie licencyjnym.
Zagadnienie odpowiedzialności za wady oprogramowania oraz świadczenia usług polegających
na usuwaniu tych wad jest dość złożonym zagadnieniem prawnym. Obecnie dość powszechną
praktyką jest oferowanie przez dostawców oprogramowania usługi dodatkowej określanej jako
„Umowa wsparcia technicznego”, „Gwarancja uaktualnień” itp. decyzja o zakupie lub nie takiej
usługi dodatkowej powinna być poprzedzona analizą odpowiednich dokumentów (zobowiązania
stron) oraz przeprowadzeniem analizy ryzyka. Możliwość uzyskania bezpośredniej i kompetentnej
pomocy technicznej ma bardzo istotne znaczenie dla zachowania ciągłości biznesu. Usługi wsparcia
technicznego są oferowane (na bardzo podobnych zasadach) zarówno dla programów
komercyjnych jak i Wolnych i Otwartych.
W przypadku oprogramowania opracowywanego na indywidualne zamówienie należy rozważć
opcję zakupu majątkowych praw autorskich. Gwarantuje to Organizacji możliwość wprowadzania
dowolnych zmian w oprogramowaniu oraz przejęcia lub przekazanie programu w celu
kontynuowania jego rozwoju innemu podmiotowi.
Powierzenie prac rozwojowych firmom (podmiotom) zewnętrznym powinno być poprzedzone
zawarciem odpowiedniego porozumienia o zachowaniu poufności.
Outsourcing oprogramowania (SaaS – Software as a Service).
Organizacja, która ustanowiła oraz eksploatuje system zarządzania bezpieczeństwem informacji
powinna dokonać szczegółowej analizy ryzyka związanego z przekazaniem części lub całości zadań
informatycznych innemu podmiotowi. Zagadnienia związane ze świadczeniem usług IT reguluje
norma ISO20000.
Jeśli podmiot mający świadczyć na rzecz Organizacji usługi IT nie posiada certyfikatu
ISO20000 należy rozważyć przeprowadzenie obiektywnego audytu proponowanych usług.
Rozdział 9: Akwizycja, rozwój i utrzymanie systemu
(C) Tomasz Barbaszewski
Materiał szkoleniowy
str. 4 z 5
System Zarządzania Bezpieczeństwem Informacji
od dobrych praktyk do certyfikacji ISO/IEC 27001
Uwagi końcowe
Systemy informatyczne rozwijają się bardzo szybko – należy więc liczyć się z koniecznością
częstego wprowadzania zmian w strukturze IT Organizacji. Opracowując SZBI należy bardzo
precyzyjnie określić odpowiedzialności związane z utrzymywaniem systemu – a w szczególności z
wykorzystywaniem aktualnych wersji oprogramowania zwierających pełny zestaw poprawek oraz
uaktualnień mających na celu jak najszybsze likwidowanie wykrywanych podatności.
Podczas zakupu praw do korzystania z oprogramowania należy sprawdzić, czy i jaki zakres
wsparcia technicznego otrzymamy od dostawcy lub producenta oprogramowania. Jeśli nie jest to
objęte umową zawierającą jednoznacznie sformułowane zobowiązania (np. dostawy ukatualnień i
poprawek) powinna zostać opracowana procedura zobowiązująca dział IT do sprawdzania, czy nie
zostały wykryte nowe podatności oraz do przeciwdziałania ich potencjalnym skutkom.
Postępowanie taki powinno być wdrożone zarówno dla programów komercyjnych dostępnych „z
półki”, jak i dla Wolnego i Otwartego Oprogramowania.
Dość częstym błędem spotykanym przy analizie możliwości wdrożenia zabezpieczeń
kryptograficznych jest utożsamianie ich jedynie z szyfrowaniem plików, zaś niedocenianie kontroli
integralności, która jest podstawowym atrybutem jakości informacji uwzględnianym przez SZBI.
Stwierdzenia, że integralność informacji jest automatycznie zapewniona przez stosowanie
uwierzytelnienia użytkowników (login / password) nie można uznać za wystarczające. Fakt, że
informacja została wprowadzona do systemu przez uwierzytelnionego użytkownika nie daje
gwarancji, że nie została ona zmieniona. Informacje o kluczowym znaczeniu dla organizacji
powinny być kontrolowane przez mechanizmy umożliwiające kontrolę ich integralności – funkcje
skrótu kryptograficznego, podpisy elektroniczne itp.
Szyfrowanie stosuje się w celu zapewnienia poufności dokumentów. Można go również
wykorzystać do zabezpieczenia poufności zapisu na twardym dysku komputera przenośnego lub
transmisji sieciowych. Ta ostatnia możliwość jest szczególnie cenna, gdy poprzez sieć
komputerową należy przesyłać transmisje o różnych wymaganiach co do poufności. Szyfrowanie
transmisji sieciowych można realizować w różnych warstwach modelu ISO/OSI.
Rozdział 9: Akwizycja, rozwój i utrzymanie systemu
(C) Tomasz Barbaszewski
Materiał szkoleniowy
str. 5 z 5