Liczba zagrożeń dotyczących danych i informacji rośnie w tempie geometrycznym. Wykorzystujemy technologię, która jest narażona na szereg zagrożeń. Nie adaptujemy, jednak odpowiedniego podejścia do zarządzania i milcząco akceptujemy ryzyka z tym związane.

Webowe systemy aplikacyjne są bardzo rozpowszechnione w biznesie. Ze względu na swoją konstrukcję, są podatne na szereg zagrożeń znanych z Internetu. Z drugiej strony, informacje prezentowane przez nie użytkownikowi są traktowane jako wiarygodne i pochodzące z zaufanego źródła. A przecież nie zawsze tak musi być.

Typowy, webowy system aplikacyjny pozwala użytkownikowi za pomocą przeglądarki internetowej komunikować się z serwerem webowym, za którym kryją się serwery aplikacyjne (logiki biznesowej) i bazy danych. Przyczyna podatności webowych systemów aplikacyjnych na zagrożenia może być zlokalizowana w wielu miejscach - poczynając od systemów operacyjnych, w których pracują serwery aplikacyjne, poprzez nieprawidłowości w administrowaniu nimi, a na błędach programistycznych i konfiguracyjnych kończąc.

Ochrona systemów aplikacyjnych

Elementy kontroli wewnętrznej, zlokalizowane w systemach aplikacyjnych, obejmują szereg kwestii dotyczących każdego etapu życia danych i informacji - od ochrony wejścia (wprowadzania danych), poprzez ochronę przechowywania i przetwarzania danych, aż do ochrony wyjścia (raportowania).

Mechanizmy kontrolne, wbudowane w system aplikacyjny, powinny uwzględniać zagadnienia takie jak:

• Autoryzacja wprowadzania danych - obejmująca kontrolę nad wszystkimi źródłami i metodami wprowadzania danych;
• Przetwarzanie wsadowe i bilansowanie - szczególnie istotne dla systemów finansowych, które często opierają się na przetwarzaniu wsadowym (np. system płacowy, z którego eksportowane są paczki przelewów do zapłaty wynagrodzeń), co pociąga za sobą potrzebę bilansowania grup transakcji i ochronę w trakcie całego cyklu przetwarzania;
• Kontrola nad wprowadzanymi danymi - identyfikacja błędnych lub nieprawidłowych danych na możliwie najwcześniejszym etapie;
• Odrzucenie/zawieszenie transakcji - identyfikowanie błędów jest pierwszą linią obrony, ale wszystkie zidentyfikowane błędy powinny zostać wyjaśnione i usunięte; stosuje się tutaj różne podejścia - od przetwarzania transakcji i oznaczania ich do późniejszej weryfikacji do zupełnego wstrzymania przetwarzania transakcji do czasu wyjaśnienia i korekcji błędów;
• Integralność przetwarzania wsadowego w systemach on-line'owych i bazach danych - kluczową rolę odgrywają tu mechanizmy zapewnienia kompletności i integralności przetwarzanych danych; wynika to z tego, że do systemów on-line'owych ma dostęp wielu użytkowników (jednocześnie) na różnych poziomach uprawnień, a dodatkowo z systemem komunikują się często inne aplikacje poprzez różnego rodzaju interfejsy;
• Procedury i kontrola przetwarzania - wprowadzone do systemu dane są wielokrotnie przetwarzane w zautomatyzowanych procedurach, które muszą obejmować wbudowane mechanizmy kontrolne; bez tego nie jest możliwe potwierdzenie kompletności i integralności, a w konsekwencji wiarygodności danych i informacji; 
• Kontrola wyjścia - polegająca na zapewnieniu, że przetwarzanie i informacje o stanie przetwarzania danych oraz żądania o wprowadzenie danych lub inne działania są kierowane przez system do właściwego użytkownika i we właściwym czasie;
• Dostęp do systemu aplikacyjnego - obejmuje mechanizmy kontroli dostępu do poszczególnych funkcji aplikacji (m.in. poprzez prawa dostępu do pozycji menu aplikacyjnego) oraz wdrożenie reguł podziału obowiązków zgodnie z logiką biznesową;
• Rejestracja zdarzeń systemowych - niezwykle istotna ze względu na to, że umożliwia śledzenie operacji wykonywanych przez użytkowników i błędów przetwarzania oraz przypisanie odpowiedzialności za wykonane operacje;
• Przetwarzanie po stronie użytkownika - użytkownicy często korzystają z dodatkowych narzędzi, które ułatwiają pracę z aplikacją i danymi (np. arkusze kalkulacyjne); wnosi to dodatkowe ryzyka, które wynikają głównie z tego, że narzędzia te często nie mają wbudowanych mechanizmów kontroli dostępu, kontroli nad zmianami i procedur zapewnienia jakości;
• Business Intelligence - systemy BI oferują nieocenioną pomoc każdemu menedżerowi, ale towarzyszy temu szczególna grupa ryzyk związanych z agregacją danych, ochroną prywatności, kompletnością informacji prezentowanych w określonym celu oraz wyrażeniu zagregowanej informacji w prawidłowej walucie.

Audyt systemu aplikacyjnego

Zgodnie ze standardem audytowania systemów informatycznych "S6 - Przeprowadzenie audytu", audytor powinien zgromadzić wystarczające, wiarygodne i adekwatne dowody audytowe, a obserwacje i wnioski audytora powinny opierać się na ich odpowiedniej analizie i interpretacji.

Najwięcej problemów nastręcza wymóg adekwatności. Wynika to z ewentualnych wątpliwości co do zakresu audytu, tj. co badać a czego nie, żeby prawidłowo wykonać audyt systemu aplikacyjnego. Wytyczna audytowania systemów informatycznych "G14 - Przegląd systemów aplikacyjnych (ISACA 2008)", podpowiada procesy (zgodnie z COBIT 4.1), które powinny zostać objęte audytem:

Podstawowe:

• PO9 - Ocena i zarządzanie ryzykiem 
• AI2 - Nabycie i utrzymanie systemów aplikacyjnych 
• DS5 - Zapewnienie bezpieczeństwa systemów 
• ME2 - Monitorowanie i ocena systemu kontroli wewnętrznej

Uzupełniające:

• PO7 - Zarządzanie zasobami ludzkimi w informatyce 
• PO8 - Zarządzanie jakością 
• A16 - Zarządzanie zmianami 
• DS3 - Zarządzanie wydajnością i potencjałem
• DS10 - Zarządzanie problemami
• DS11 - Zarządzanie danymi 

Wytyczna podpowiada też, jakie aspekty działania tych procesów powinny być brane pod uwagę w trakcie audytu, tj. jakie cechy informacji powinny być przez nie zapewnione:

Podstawowe:

• Dostępność 
• Wiarygodność 
• Integralność 
• Poufność 

Uzupełniające:

• Zgodność 
• Skuteczność 
• Efektywność 
  
   

Ryzyka, które należy zidentyfikować, obejmują m.in.:

• Ryzyka niedostępności systemu związane z brakiem zdolności do działania;
• Ryzyka bezpieczeństwa informacji związane z nieuprawnionym dostępem do systemu i/lub danych;
• Ryzyka integralności związane z niekompletnym, nieprawidłowym, opóźnionym lub nieuprawnionym przetwarzaniem danych;
• Ryzyka związane z utrzymaniem systemu wynikające z braku możliwości aktualizacji systemu w wymaganym czasie z zachowaniem dostępności, bezpieczeństwa i integralności systemu i danych;
• Ryzyka związane z danymi dotyczące ich kompletności, integralności, poufności, prywatności i prawidłowości.

Odpowiedź na ryzyko związane z systemem aplikacyjnym może opierać się na mechanizmach wbudowanych w systemy aplikacyjne, procedurach manualnych lub kombinacji powyższych. Przykładem może być tutaj zautomatyzowana procedura uzgadniania zamówień, faktur i dokumentów rozchodów magazynowych, ale również raporty wyjątków przedstawiane do akceptacji wyższego kierownictwa.

Nader często ocena systemu aplikacyjnego wymaga od audytora wiedzy i zrozumienia ogólnych mechanizmów kontrolnych, które nie są specyficzne dla aplikacji, takich jak np. ochrona dostępu fizycznego, zarządzanie siecią, czy system kopii zapasowych.

Procedura audytu

Dla prawidłowego wykonania audytu, trzeba wykonać określone procedury, obejmujące co najmniej udokumentowanie przepływu transakcji oraz identyfikację i testy aplikacyjnych mechanizmów kontrolnych. Dokumentując przepływ transakcji, audytor powinien uwzględnić zarówno systemowe jak i manualne aspekty obsługi i funkcjonowania systemu.

Kluczowe zagadnienia objęte dokumentacją, to:

• Wprowadzanie danych (manualne i zautomatyzowane, np. interfejsy systemowe), 
• Algorytmy przetwarzania danych, zasady przechowywania danych oraz 
• System raportowania informacji.

Najczęściej spotykaną techniką dokumentacji przepływów transakcji są diagramy przepływowe danych lub opis przepływów.

Informacje na temat przepływu transakcji należy zweryfikować, śledząc cały proces lub transakcje i potwierdzając kluczowe mechanizmy kontrolne. Na tym etapie audytor nie dokonuje jeszcze oceny systemu aplikacyjnego, a jedynie potwierdza swoje zrozumienie badanego obszaru.

Kolejnym krokiem jest identyfikacja i testy mechanizmów kontrolnych objętych systemem aplikacyjnym. W ramach tego etapu audytor określa mechanizmy kontrolne, które stanowią odpowiedź na zidentyfikowane ryzyka i sprawdza, czy mechanizmy te działają zgodnie z założeniami.

Procedury testowe wykonywane przez audytora powinny zapewnić zgromadzenie odpowiednich dowodów audytowych. Tam gdzie to możliwe audytor może wspierać się narzędziami usprawniającymi jego pracę, czyli CAAT (ang. Computer-Assisted Audit Techniques).

Raportowanie wyników

Wszelkie słabości systemu kontroli wewnętrznej wynikające z braku mechanizmów kontrolnych lub ich niezgodności z założeniami, powinny zostać uwzględnione w raporcie. Powinna się tam także znaleźć informacja na temat ogólnych mechanizmów kontrolnych, gdyż nieprawidłowości w tym obszarze mogą wpływać na system aplikacyjny.

Wszelkim zaobserwowanym nieprawidłowościom powinny towarzyszyć rekomendacje usprawnień, czyli proponowana odpowiedź na ryzyko. Audytor powinien w nich sugerować, a nie projektować rozwiązania, gdyż nie powinien on m.in. podejmować decyzji inwestycyjnych związanych ze sposobem unikania ryzyka.