Diagramy to temat bardzo długi i ile jest QSA tyle jest podejść i opcji. To co prezentujemy poniżej to nasza wizja i opinia, bazująca na ponad 200 ukończonych assessmentach oraz kilkuset projektach doradczych. Ważne jest także, że nie ma idealnego diagramu, który będzie “pasował” każdemu QSA.  

Ważne, aby oddawał on sens i założenia standardu oraz był stosunkowo łatwy w utrzymaniu.  

Jest to wymóg standardu PCI DSS który wyraźnie określa, że organizacja musi posiadać dokładny diagram sieciowy (network diagram) oraz diagram przepływu danych (data flow diagram).  Wymóg ten opisany jest w punktach 1.1.2 i 1.1.3 w wersji standardu 3.2.1 oraz w punktach 1.2.3 i 1.2.4 w wersji 4.0. 

Po co w ogóle nam taki diagram? Odpowiadając najprościej: by organizacja miała świadomość, jakie sieci wchodzą w skład jej architektury sieciowej oraz przez które z tych sieci, w jaki sposób (jawny czy zaszyfrowany) oraz gdzie i do kogo przepływają dane (nie tylko kartowe). 

Dodatkowo – po to, aby zwizualizować zakres certyfikacji oraz pokazać, ze mamy udokumentowany cały przebieg danych kartowych przez organizację oraz zidentyfikowane systemy, osoby wspierające środowisko. To naprawdę pomaga przy ustaleniu i potwierdzaniu zakresu certyfikacji – z diagramu bardzo łatwo ustalimy, czy organizacja przechowuje dane kartowe, jesli tak to gdzie oraz czy nie ma luk w procesie przetwarzania kart (np nagle dane pojawiają sie w postaci jawnej)  

Zdarza się, że firmy umniejszają znaczenie tworzenia i posiadania diagramów – to błąd już na wstępie certyfikacji, gdyż czytelny diagram odzwierciedlający topografię zasobów IT i powiązanych z nimi danych stanowi istotną część procedury oceny zgodności z PCI. Pozwala nie tylko na potwierdzenie zakresu, ale także jasno pokazuje granice co w zakresie jest a co jest poza zakresem.  

Taki diagram może być wykorzystany nie tylko do certyfikacji PCI, ale także przy innych programach – takich jak ISO 27001, wymogi i standardy EBA (European Banking Authority) i/lub KNF (Komisja Nadzoru Finansowego)  

Mały QSA hint –  kompletny diagram pozwala uniknąć pytań po ukończeniu assessmentu i podczas pisania raportu – jesli na nim mamy komplet informacji nie musimy pytać się klienta o ilość adresów IP, VLANy w zakresie etc. Diagram pozwala samodzielnie zweryfikować czy dobrze wykonałeś testy penetracyjne, skany podatności, skany ASV etc. To mniej pytań do Ciebie i szybciej dostarczony raport.  

1. Ilość diagramów – Żaden ze znanych standardów nie precyzuje ilości posiadanych diagramów. Z doświadczenia możemy powiedzieć, że nie ma jednej dobrej odpowiedzi. Czasami jeden diagram wystarczy, czasami lepiej jest zrobić więcej niż jeden diagram (szczególnie dla skomplikowanych systemów informatycznych).  
2. Aktualność – Nie jest ważna ilość – ważna jest jakość oraz aktualność. Diagram musi być aktualny – przeglądany minimum raz do roku a idealnie po każdej większej zmianie – tak aby oddawał to co jest faktycznie w środowisku IT. Każda aktualizacja musi być odnotowana (idealnie na diagramie) tak aby mieć świadomość, że przegląda sie aktualną, ostateczną wersję.  
3. Przejrzystość – diagram musi być przejrzysty. Zbyt szczegółowy diagram nie jest dobrym przykładem – czasami nie ma sensu rysować wszystkich serwerów – wystarczy grupa lub rola. Diagram ma być łatwy do odczytania i zrozumienia. Zdarza się, że zbyt wiele detali i przesycenie rysunku informacjami, czyni go nieczytelnym i niezrozumiałym. A chodzi przecież o to, by osoba, której przyjdzie czytać ów diagram, potrafiła szybko i łatwo zidentyfikować elementy sieci, jej segmenty, przepływy danych, odróżnić środowisko CDE od non-CDE czy obszary objęte lub nie zakresem oceny. Treściwy diagram nie oznacza diagramu „zaśmieconego” niepotrzebnymi drobiazgowymi informacjami. Idealny diagram powinien być przystępny i jednoznaczny dla odbiorcy w swojej prostocie.  
4. Czytelność – Używaj symboli, obrazków, kolorów, strzałek, itd., aby zilustrować środowisko Twojej firmy i sposób przepływu przez nie danych kartowych. Bardzo pomocne okazuje się 
   1. stosowanie odpowiednich ikon dla typów lub grup systemów (np. symbol firewall`a, routera, serwera, bazy danych – wystarczy ikonka – nie trzeba wówczas dodawać podpisu),  
   2. zastosowanie kolorów i/lub ramek (np. jako wyróżnienie segmentu sieci, czy przepływu danych w sposób jawny lub zaszyfrowany lub oznaczenie czy są to dane kartowe czy inne).  
   3. Dużo bardziej sprawdza się stosowanie krótkich opisów tych elementów (np. firewall, serwer DB czy sieć DMZ), choć oczywiście podanie konkretnych elementów systemu i powiązanie ich z konkretnymi nazwami, modelem, typem, nazwą sieci, jest niemniej istotne. Dla twórcy diagramu, nazwa DBSVRLAN321 może być jak najbardziej oczywista, dla czytelnika niekoniecznie. Warto więc, załączyć klucz będący częścią diagramu lub osobny dokument powiązany z diagramem, tak, aby odbiorca mógł łatwo rozszyfrować wszystkie nazwy, kolory, symbole. 
5. Kompletność – W zależności od stopnia złożoności sieci i procesów w Twojej organizacji, możesz połączyć diagram sieciowy i przepływu danych w jeden lub może istnieć konieczność posiadania wielu diagramów (osobny diagram sieciowy, osobny diagram przepływu danych, dodatkowe diagramy sieciowe niższego szczebla – bardziej szczegółowe). 

 Poniżej przykład diagramu dla środowiska hostowanego w DC (środowisko fizyczne) bez rozwiązań chmurowych. Zwróć uwagę na to czy diagram zawiera 5 elementów, o których piszemy powyżej oraz czy jest dla Ciebie jasny i zrozumiały.  

Masz pytania jeśli chodzi o diagram lub ogólnie z PCI DSS?   – odezwij się do nas. Mamy ponad 15 lat doświadczeń pracy ze standardem PCI DSS – znajdziemy rozwiązanie także i na Twój problem.