| Termin | Definicja |
|---|---|
| odpowiedzialność za incydent | Odpowiedzialność za incydent to wskazanie osób i ról zobowiązanych do reakcji oraz raportowania zdarzenia. Zakres odpowiedzialności za incydent informatycznyOdpowiedzialność za incydent informatyczny oznacza przypisanie konkretnym osobom zadań związanych z wykryciem, potwierdzeniem, obsługą, dokumentowaniem i zamknięciem zdarzenia. Incydentem może być między innymi infekcja złośliwym oprogramowaniem, nieautoryzowana zmiana konfiguracji, utrata dostępu do systemu, uszkodzenie nośnika danych, powtarzające się awarie urządzenia albo podejrzane logowanie do konta. Sam fakt wskazania właściciela systemu nie wystarcza, ponieważ w praktyce różne etapy reakcji mogą wymagać udziału użytkownika, technika, administratora oraz osoby zatwierdzającej przywrócenie pracy. W dobrze zorganizowanym procesie każda rola ma określony zakres uprawnień i obowiązków. Osoba zgłaszająca przekazuje czas wystąpienia problemu, objawy, komunikaty błędów i wykonane już czynności. Osoba przyjmująca zgłoszenie nadaje identyfikator incydentu, ustala priorytet i pilnuje kompletności danych. Technik lub administrator zabezpiecza urządzenie, zbiera dowody diagnostyczne i wykonuje działania naprawcze. Właściciel usługi ocenia wpływ na pracę użytkowników, a osoba odpowiedzialna za raportowanie przekazuje ustalenia zainteresowanym odbiorcom. Taki podział ogranicza ryzyko, że kilka osób wykona sprzeczne czynności albo że nikt nie podejmie decyzji. Role, eskalacja i decyzje podczas obsługi zdarzeniaOdpowiedzialność powinna obejmować zarówno wykonanie zadania, jak i podjęcie decyzji. Technik może na przykład odłączyć laptop od sieci, zatrzymać podejrzany proces lub wykonać kopię obrazu dysku, ale nie powinien samodzielnie usuwać danych potrzebnych do późniejszej analizy. Właściciel urządzenia może potwierdzić, że określone pliki są potrzebne do pracy, natomiast decyzję o ich odtworzeniu z kopii zapasowej powinien podjąć pracownik dysponujący odpowiednimi uprawnieniami i wiedzą o stanie systemu. W dokumentacji warto rozdzielić osobę wykonującą czynność od osoby, która ją zatwierdziła. Eskalacja jest potrzebna wtedy, gdy incydent przekracza ustalony poziom wpływu, wymaga dostępu administracyjnego, dotyczy wielu urządzeń albo nie może zostać rozwiązany w przewidzianym czasie. Zgłoszenie powinno zawierać warunek eskalacji, adresata oraz wymagane informacje. Przykładem może być przekazanie sprawy do specjalisty od odzyskiwania danych po stwierdzeniu uszkodzeń sektorów dysku, do administratora sieci po wykryciu problemu z wieloma komputerami albo do dostawcy oprogramowania po odtworzeniu błędu w aktualnej wersji aplikacji. Każda zmiana właściciela incydentu powinna być zapisana wraz z datą, godziną i powodem przekazania. Raportowanie nie powinno ograniczać się do informacji, że urządzenie ponownie się uruchomiło. Raport techniczny powinien wskazywać objawy, zakres oddziaływania, oś czasu, wykonane czynności, wyniki testów, przyczynę potwierdzoną albo hipotezę wymagającą dalszej weryfikacji oraz stan końcowy. Jeżeli przyczyny nie udało się ustalić, należy napisać to wprost i odnotować, jakie dane były niedostępne. Dzięki temu późniejsza osoba nie traktuje przypuszczenia jako faktu i może kontynuować diagnostykę bez powtarzania tych samych działań. Ślad audytowy i kontrola wykonanych czynnościPodstawowym narzędziem kontroli odpowiedzialności jest chronologiczny rejestr incydentu. Powinny w nim znaleźć się co najmniej: identyfikator zgłoszenia, urządzenie lub usługa, osoba zgłaszająca, osoby uczestniczące w obsłudze, czas wykrycia, czas rozpoczęcia reakcji, opis wpływu, wykonane czynności i wynik weryfikacji. Przy pracy na komputerze przydatne są również nazwy plików logów, numery wersji sterowników lub aplikacji, informacje o ostatniej aktualizacji oraz odczyty diagnostyczne, o ile ich zebranie nie zmienia stanu badanego systemu. Każda czynność powinna być opisana w sposób możliwy do odtworzenia. Zamiast wpisu „naprawiono system” lepiej zapisać, że uruchomiono sprawdzanie integralności plików systemowych, odinstalowano wskazaną aktualizację, wymieniono uszkodzony moduł pamięci albo odtworzono konfigurację z określonego punktu. Należy odnotować także czynności nieskuteczne, ponieważ ich pominięcie może prowadzić do ponownego wykonania ryzykownej operacji. Jeżeli zmieniono hasło, regułę zapory, ustawienie rozruchu lub sterownik, zapis powinien wskazywać zakres zmiany, ale nie powinien ujawniać poufnych wartości, takich jak samo hasło. Zamknięcie incydentu wymaga sprawdzenia, czy usunięto objaw, przywrócono wymagane funkcje i nie pojawiły się nowe błędy. Test może obejmować uruchomienie systemu, odczyt stanu urządzenia, wykonanie kontrolnego połączenia sieciowego, otwarcie używanej aplikacji albo sprawdzenie odczytów SMART po wymianie dysku. Osoba zamykająca sprawę powinna mieć podstawę do stwierdzenia, że rezultat jest poprawny. Jeżeli pozostaje ryzyko nawrotu, incydent można zamknąć jako obsłużony, ale należy utworzyć osobne zadanie dotyczące przyczyny źródłowej, monitorowania lub modernizacji sprzętu. Odpowiedzialność przy naprawie laptopa i komputera PCW przypadku domowego lub biurowego laptopa odpowiedzialność za incydent zaczyna się od dokładnego przyjęcia urządzenia i opisu problemu. Należy ustalić, czy komputer nie uruchamia się wcale, wyłącza się pod obciążeniem, traci połączenie z siecią, wyświetla błędy systemowe, przegrzewa się, działa niestabilnie po aktualizacji albo ma objawy uszkodzenia dysku. Istotne są także informacje o tym, kiedy problem wystąpił, czy urządzenie zostało zalane lub uderzone, czy wykonywano samodzielne naprawy oraz czy użytkownik posiada kopię potrzebnych plików. Bez tych danych łatwo pomylić awarię sprzętową z błędem systemu lub niewłaściwą konfiguracją. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, dlatego w dokumentacji serwisowej można rozdzielić osobę przyjmującą sprzęt, technika wykonującego diagnostykę oraz osobę przekazującą klientowi wynik prac. Taki zapis powinien obejmować stan urządzenia przy przyjęciu, wykonane testy, wymienione elementy, zastosowane ustawienia i rezultat kontroli po naprawie. Przy wymianie dysku, pamięci RAM, zasilacza, układu chłodzenia lub innego podzespołu warto zapisać identyfikację części i wynik testu obciążeniowego albo funkcjonalnego, jeżeli taki test jest właściwy dla danego problemu. Końcowa informacja dla użytkownika powinna jasno wskazywać, co zostało potwierdzone, co wykonano i jakie ograniczenia nadal występują. Jeżeli komputer działa, lecz przyczyną była niestabilna pamięć, zużyty nośnik albo przegrzewanie procesora, należy podać tę przyczynę wraz z zakresem przeprowadzonych testów. Jeżeli diagnoza nie jest jednoznaczna, nie wolno przedstawiać przypuszczenia jako pewnego rozpoznania. Odpowiedzialność za incydent kończy się dopiero wtedy, gdy istnieje zapis decyzji, rezultat naprawy został sprawdzony, a użytkownik otrzymał zrozumiałą informację o stanie urządzenia. |