SAP publikuje noty bezpieczeństwa w cyklu miesięcznym, w drugi wtorek miesiąca. Dla zespołów utrzymujących SAP oznacza to powtarzalną decyzję: które noty dotyczą naszego środowiska, które trzeba wdrożyć natychmiast, a które mogą poczekać do najbliższego okna serwisowego.
Przejmujemy tę pracę - od analizy not, przez ocenę wpływu na konkretny krajobraz SAP, po wdrożenie poprawek i testy regresji.
Najnowsze wydanie ·
20 pozycji zamiast sierpniowych 31, więc lista wygląda na spokojną. Nie jest. Cztery noty krytyczne leżą w czterech różnych warstwach - jądrze, komunikacji między instancjami, bibliotece npm i na stacji roboczej - i żadna z nich nie trafia tam, gdzie zwykle patrzy proces patchowania ERP.
Czytaj analizę tego wydaniaSurowa lista not SAP nie odpowiada na pytanie, co zrobić w konkretnym środowisku. Filtrujemy noty pod kątem faktycznie używanych komponentów, wersji i konfiguracji, a wynik przekazujemy jako listę działań z priorytetem, nie jako biuletyn do samodzielnej interpretacji.
Okres między publikacją noty a wdrożeniem poprawki to okno, w którym podatność jest znana publicznie i pozostaje otwarta. Stały proces miesięczny skraca ten czas, ponieważ analiza nie zaczyna się za każdym razem od zera.
Regularna, udokumentowana obsługa not bezpieczeństwa jest jednym z elementów, o które pytają audytorzy w kontekście NIS2, DORA i KSC. Z każdego cyklu pozostaje zapis: co przeanalizowano, co wdrożono i na jakiej podstawie odłożono pozostałe pozycje.
Comiesięczny przegląd not to praca powtarzalna, która rywalizuje o czas z projektami rozwojowymi. Przejęcie jej przez zewnętrzny zespół zdejmuje z zespołu wewnętrznego stały, cykliczny obowiązek.
Po każdym Patch Day przeglądamy opublikowane noty, weryfikujemy oceny CVSS, opisy podatności i warunki eksploatacji. Wskazujemy pozycje istotne dla komponentów faktycznie obecnych w środowisku klienta.
Mapujemy noty na konkretne systemy, wersje, pakiety rozszerzeń i konfiguracje. Efektem jest lista pozycji dotyczących danego środowiska, oddzielona od tych, które go nie obejmują.
Dzielimy noty na wymagające działania natychmiastowego, wdrożenia w najbliższym oknie serwisowym oraz obsługi w cyklu planowym. Priorytet opiera się na ocenie CVSS, ekspozycji systemu i krytyczności procesu biznesowego.
Wdrażamy noty w środowiskach nieprodukcyjnych, weryfikujemy skutki, a następnie przeprowadzamy wdrożenie produkcyjne w ustalonym oknie. Zakres testów regresji ustalamy na podstawie krytyczności procesów.
Część not dotyczy podatności, których odpowiedniki mogą występować także w kodzie własnym. Skanujemy custom ABAP z użyciem SAP Code Vulnerability Analyzer, aby wychwycić analogiczne wzorce poza standardem.
Z każdego cyklu przygotowujemy zapis: analizowane noty, decyzje, wdrożone poprawki, pozycje odłożone wraz z uzasadnieniem. Dokument może wspierać audyt wewnętrzny, zewnętrzny lub regulacyjny.
Cykl zaczyna się w dniu publikacji not, czyli w drugi wtorek miesiąca. Przeglądamy opublikowane noty bezpieczeństwa i wstępnie oddzielamy pozycje istotne dla środowisk objętych wsparciem od tych, które ich nie dotyczą.
Następnie wykonujemy ocenę wpływu. Noty mapujemy na konkretne systemy, wersje i konfiguracje klienta, a przy pozycjach krytycznych weryfikujemy warunki, w których podatność daje się wykorzystać.
Na tej podstawie przygotowujemy plan wdrożenia z podziałem na działania natychmiastowe, pozycje na najbliższe okno serwisowe oraz obsługę w cyklu planowym.
Poprawki wdrażamy najpierw w środowiskach nieprodukcyjnych, potem produkcyjnie w ustalonym oknie, z zakresem testów regresji dobranym do krytyczności procesów.
Cykl zamyka raport: co przeanalizowano, co wdrożono, co odłożono i na jakiej podstawie. Ten sam Patch Day komentujemy publicznie w cyklu „Bezpieczny Wtorek ze SNOK".
Stack technologiczny
Analizy Patch Day prowadzimy w oparciu o narzędzia SAP oraz platformy partnerskie, z którymi pracujemy w projektach produkcyjnych.
SAP publikuje noty bezpieczeństwa w drugi wtorek każdego miesiąca. Poza tym cyklem SAP może opublikować notę poza harmonogramem, jeśli podatność jest krytyczna i wymaga natychmiastowej reakcji.
Nie. Część not dotyczy komponentów, których dana organizacja nie używa, więc nie wymaga żadnego działania. Wśród pozostałych priorytet zależy od oceny CVSS, ekspozycji systemu, warunków wykorzystania podatności oraz krytyczności procesu biznesowego. Dlatego pierwszym krokiem jest ocena wpływu na konkretne środowisko, a nie wdrażanie całej listy.
Regulacje nie wskazują SAP Security Patch Day wprost, ale wymagają zarządzania podatnościami i wykazania, że organizacja robi to w sposób uporządkowany. Udokumentowany, powtarzalny proces obsługi not bezpieczeństwa jest praktycznym dowodem takiego zarządzania. Szerzej opisujemy to w ramach audytu zgodności NIS2, DORA i KSC.
Tak. Noty SAP dotyczą standardu, ale podobne wzorce podatności - na przykład brak kontroli autoryzacji, SQL injection czy path traversal - często występują również w custom kodzie ABAP. Dlatego cykl obejmuje skanowanie kodu własnego, między innymi z użyciem SAP Code Vulnerability Analyzer.
Tak. Część organizacji zleca wyłącznie analizę i priorytetyzację, a wdrożenie wykonuje własnym zespołem SAP Basis. Możliwy jest też model odwrotny oraz pełna obsługa cyklu po naszej stronie.
Każdy SAP Security Patch Day komentujemy w cyklu „Bezpieczny Wtorek ze SNOK". Poniżej pełne archiwum analiz, od najnowszej.
