Bezpieczeństwo systemu AMODIT na etapie projektowania i tworzenia rozwiązań

W tym artykule przedstawiamy odpowiedzi na pytania lub zagadnienia, które pojawiają się w kontekście bezpieczeństwa systemu AMODIT na etapie projektowania i tworzenia rozwiązań bazujących na nim wg zasad Security By Design.

Pytanie lub zagadnienie dotyczące bezpieczeństwa Jak to jest zrealizowane w systemie AMODIT
Zbędne funkcjonalności nie powinny być instalowane. System AMODIT jest systemem uniwersalnym i skompilowany kod zawiera wiele funkcjonalności, które nie w każdym przypadku są lub muszą być używane. Niestety nie ma technicznych możliwości, aby dostarczać tego typu system w inny sposób. Natomiast pewne komponenty, w szczególności integracyjne, nie są dostarczane, o ile nie są potrzebne w konkretnym wdrożeniu.
Zainstalowane funkcje nie mogą mieć nieudokumentowanych funkcjonalności,  w szczególności tych, które naruszają interesy operatora/użytkownika w zakresie bezpieczeństwa i prywatności. System nie zawiera żadnych tego typu funkcjonalności.
Dostarczone rozwiązanie powinno być wolne od złośliwego oprogramowania, oprogramowania szpiegującego, ukrytych funkcji, nieudokumentowanych tylnych furtek lub innych niezatwierdzonych lub niechcianych funkcji, takich jak nieautoryzowane przekazywanie danych, zbieranie danych analitycznych bez wiedzy użytkownika. System nie zawiera takich funkcjonalności. System natomiast gromadzi szereg informacji statystycznych, monitorujących w celu późniejszej diagnozy błędów czy analizy wydajności. Niemniej to, co gromadzi system i w jakiej postaci, jest jawne.
Dostarczone rozwiązanie powinno posiadać funkcje rejestrowania i audytu. Funkcje te powinny być uwzględnione na etapie projektowania i tworzenia rozwiązania. Jednocześnie funkcje te powinny opierać się na otwartych, interoperacyjnych standardach i najlepszych praktykach, aby prawidłowo współpracować z systemami zarządzania informacjami i zdarzeniami dotyczącymi bezpieczeństwa (SIEM) oraz systemami rejestrowania i monitorowania. System rejestruje praktycznie każdą czynność użytkowników i administratorów, dzięki czemu możliwe jest przeprowadzenie audytu. Udostępniana jest struktura bazy danych, tak aby służby IT mogły analizować gromadzone przez AMODIT dane, w tym dane monitorujące.
Dostarczone rozwiązanie powinno rejestrować działania użytkowników w systemie oraz zdarzenia i błędy związane z bezpieczeństwem. Rejestracja tych danych powinna odbywać się w formacie, który może być przeglądany i analizowany podczas wykonywania operacji lub po ich zakończeniu. System rejestruje praktycznie każdą czynność użytkowników i administratorów dzięki czemu możliwe jest prowadzenie audytu.
Pliki dzienników/logi powinny być chronione przed manipulacją. Pliki logów są tabelą bazy danych systemu AMODIT i nie podlegają modyfikacji z poziomu UI systemu. Od strony bazy danych mogą być przeglądane i edytowane przez administratora.
Dostarczone rozwiązanie powinno zapewniać powszechnie akceptowany standardowy czas systemowy oraz możliwość synchronizacji go z zewnętrznym źródłem czasu w celu uzyskania dokładności czasu systemowego co do sekundy. Czas pobierany jest z systemu Windows Server, a synchronizacja wykonywana jest zgodnie z ustawieniami w Windows.
Rozwiązanie nie korzysta z technologii, protokołów  i funkcjonalności, które są przestarzałe lub już uznane za niebezpieczne (np. SSL 3.0, TLS 1.0, MD5, RC4, etc.). System nie używa przestarzałych technologii.
Kompletne rozwiązanie wraz ze wszystkimi jego komponentami, czyli rozszerzeniami  i ulepszeniami, musi być wolne od znanych podatności oraz zdolne do usuwania  i łagodzenia nowych podatności. System jest na bieżąco monitorowany pod kątem podatności i każde są niezwłocznie zabezpieczane.
W rozwiązaniu nie należy stosować środków kryptograficznych uznanych za podatne lub skompromitowane, również takich wobec których istnieją przesłanki, że byłyby one podatne na kryptoanalizę (ogólnie – przełamanie szyfrowania). Jeżeli w systemie stosowane są środki kryptograficzne, np. do szyfrowania zawartości załączanych plików, to używany jest algorytm SHA-256.
Dane wrażliwe (np. dane uwierzytelniające) w rozwiązaniu muszą być odpowiednio przechowywane i chronione. Stosowany jest algorytm SHA-256, ponadto oferujemy dodatkowy moduł ochrony danych wrażliwych, który umożliwia taką organizację dostępów, że nawet administrator IT, znający rozwiązanie, nie jest w stanie uzyskać dostępu do danych wrażliwych bez autoryzacji osoby z biznesu odpowiedzialnej za te dane.
Jeżeli rozwiązanie przesyła dane wrażliwe (np. dane uwierzytelniające, dane identyfikacyjne), ich transmitowanie powinno być realizowane wyłącznie w formie zaszyfrowanej. Transmisja szyfrowana jest z użyciem protokołu TLS 1.2.
W rozwiązaniu należy stosować tylko ustalone i dobrze znane algorytmy szyfrowania oraz bezpieczne długości kluczy szyfrowania, które zgodnie z aktualnym stanem wiedzy są uważane za bezpieczne. Podejrzane i skompromitowane algorytmy szyfrowania są niedozwolone. Stosowany jest algorytm SHA-256.
Bieżące kontrole autentyczności i integralności podczas normalnej pracy aplikacji/systemu powinny wykrywać i wskazywać wszelkie nieautoryzowane zmiany w konfiguracji systemu. Dostęp do zmian konfiguracyjnych jest tylko i wyłącznie dla administratorów systemu. Każda zmiana jest rejestrowana co do czasu i osoby ją wykonującej. Zmiany ustawień systemowych mogą być zabezpieczone zasadą 4Eyes, która powoduje, że każda zmiana konfiguracyjna musi być zatwierdzona przez drugiego administratora.
Dostawca w obszarze dostarczanego systemu oraz jego wsparcia powinien posiadać wdrożony plany ciągłości działania. W przypadku wdrożeń opartych o system AMODIT działający w chmurze stosowane jest m.in. zwielokrotnienie infrastruktury.
Dostawca rozwiązania powinien posiadać i utrzymywać:
  • aktualny ważny certyfikat bezpieczeństwa w odpowiednim obszarze;
  • równoważy certyfikat bezpieczeństwa w odpowiednim obszarze.
 W systemie stosowane są wytyczne zgodne z normą ISO/IEC 27001:2013.
W celu udowodnienia spełniania przez rozwiązanie lub usługę, wymagań bezpieczeństwa dostawca powinien udostępnić dowody spełnienia wymagań określonych przez takie certyfikaty lub inne wskazane metodyki / procesy czy deklarowane postępowanie. W systemie stosowane są wytyczne zgodne z normą ISO/IEC 27001:2013.
Dostawca powinien być w stanie udowodnić stosowanie odpowiednich dyrektyw/wytycznych dotyczących bezpieczeństwa informacji, które mają zastosowanie do jego produktu/usługi. W systemie stosowane są wytyczne zgodne z normą ISO/IEC 27001:2013.
Przedmiot dostawy, tj. produkt, rozwiązanie, system, platforma podlegający dostawie lub udostępnieniu (np. w ramach usług SaaS) muszą podlegać okresowym testom bezpieczeństwa prowadzonymi przez niezależny od dostawcy podmiot, zaś testy powinny być prowadzone zgodnie ze standardami i wytycznymi branżowymi dla danego typu produktu (np. OWASP). Przez testy bezpieczeństwa rozumiane są:
  • testy penetracyjne (w różnym modelu i zakresie);
  • analizy podatności (w różnym zakresie [zewn/wewn/z autoryzacją]);
  • testy jakościowe, w tym wydajnościowe i obciążeniowe.
 Prowadzone są okresowe testy bezpieczeństwa wykonywane na nasze zlecenie oraz niezależnie przez niektórych z naszych klientów. Na podstawie wyników testów wprowadzane są stosowne zmiany.
Czy dostawca wyraża zgodę na inicjalne, a następnie okresowe (co najmniej raz na pół roku), testy bezpieczeństwa prowadzone przez Zamawiającego, dostarczanego i/lub udostępnionego rozwiązania. Dobór typu, liczby i zakres testów jest uzależniony od typu dostarczanego produktu i usługi, zakresu powiązanych ryzyk i wpływu na usługi Zamawiającego.Wynik testów każdorazowo będzie konsultowany z dostawcą, który zobowiązuje się w skończonym czasie znaleźć rozwiązanie wskazanych problemów, podatności i luk bezpieczeństwa. Jako producent systemu AMODIT i dostawca rozwiązań bazujących  na tym systemie wyrażamy taką zgodę. Podobne rozwiązania stosujemy z innymi Klientami.
Aktualizacja