Cisco License On-Prem (dawniej SSM On-Prem): gdy poprawką jest migracja produktu, a nie patch

7 października Cisco opublikowało Security Hardening Release dla Cisco License On-Prem, czyli produktu znanego wcześniej jako Cisco Smart Software Manager On-Prem. W advisory są cztery CVE, najwyższe z CVSS 10.0. Podatne jest każde wydanie, niezależnie od konfiguracji, i nie ma obejść. Linia 10 dostała poprawkę w 10-202609. Dla linii 9 i starszych w tabeli poprawek jest tylko jedno zdanie: „Migrate to a fixed release”. W praktyce zamknięcie findingu oznacza więc projekt migracji, a pierwszym problemem jest odnalezienie serwera licencji, który ktoś kiedyś postawił i o którym wszyscy zapomnieli.

Cztery CVE, czyli cztery klasy błędów

Cisco stosuje tu ten sam model co w innych hardening release: wewnętrznie znalezione błędy grupuje według CWE i każdej grupie nadaje jedno CVE. Ocena CVSS opisuje najpoważniejszy błąd w grupie, a nie każdy z nich. Opisywałem ten model przy Secure Workload, gdzie jedno CVE obejmowało wiele luk. Wektory poniżej pochodzą z rekordów NVD, w których źródłem oceny jest psirt@cisco.com:

Jedna poprawka do popularnego skrótu „cztery błędy bez uwierzytelnienia”: trzy CVE mają PR:N, ale CVE-2026-76484 (code injection) ma PR:L, więc wymaga konta z niskimi uprawnieniami. W praktyce to niewiele zmienia, bo CVE-2026-76480 dotyczy braku uwierzytelnienia, a CVE-2026-76483 niewystarczającej ochrony poświadczeń. Advisory nie opisuje jednak, czy da się je połączyć w łańcuch, więc tego nie zakładam. Opisy w NVD są ogólne i nie podają podatnych endpointów, dlatego nie ma tu niczego, co dałoby się przełożyć na reguły detekcji.

Tabela poprawek: patch dla linii 10, migracja dla linii 9

W tabeli nie ma wydania linii 9 z poprawką. Kroki aktualizacji i migracji Cisco odsyła do release notes 10-202609. Tego PDF nie udało mi się odczytać, więc nie piszę, czy przejście z 9 na 10 to aktualizacja w miejscu, czy nowe wdrożenie z eksportem danych. Sprawdź to w dokumencie, zanim oszacujesz pracę. Dla procesu VM ważniejszy jest inny wniosek: dla starszej linii nie istnieje fixed version, którą skaner mógłby wskazać jako cel. Jest tylko inny produkt pod inną nazwą.

Inwentarz: serwer licencji pod starą nazwą

Najtrudniejsze w tym przypadku jest wykrycie, nie ocena ryzyka. Lokalny serwer licencji to typowy zasób, który ktoś wdrożył przy zakupie licencji, skonfigurował raz i od tamtej pory nikt go nie aktualizuje, bo przecież „tylko liczy licencje”. Kilka powodów, dla których może nie pojawić się w raporcie exposure:

1. Zmiana nazwy. Advisory i nowsze dane mówią o „Cisco License On-Prem”. CMDB, rejestr umów albo stary opis maszyny wirtualnej mówią o „Smart Software Manager On-Prem” lub „SSM On-Prem”. Jeśli dopasowujesz advisory do zasobów po nazwie produktu, wyszukaj obie nazwy i oba skróty.
2. Format wersji. Wersje mają postać linia-RRRRMM (9-202601, 10-202609). Reguła porównująca wersje musi najpierw wyciągnąć linię, bo dla linii 9 nie ma progu „naprawiono od wersji”, tylko warunek „każda wersja tej linii = migracja”.
3. Właściciel. Serwer licencji często należy do zespołu sieciowego albo do osoby, która zajmowała się zakupami, a nie do zespołu, który zarządza serwerami. Bez przypisanego właściciela finding migracji nie trafi do nikogo, kto może zaplanować okno serwisowe.

Advisory nie opisuje, jakie dane przechowuje serwer ani z czym się komunikuje, więc ekspozycję trzeba ustalić u siebie: czy interfejs webowy i API są osiągalne z internetu lub z szerokich segmentów sieci, czy z nich korzystają urządzenia sieciowe, które zgłaszają do niego użycie licencji. Przy AV:N, PR:N i SSVC „automatable: yes” ograniczenie dostępu sieciowego to rozsądny środek tymczasowy na czas migracji. To mój wniosek, nie obejście od Cisco, które wprost pisze, że obejść nie ma.

EOL w procesie VM: finding, który zamyka projekt, a nie patch

Taki przypadek łatwo źle obsłużyć. Typowy ticket „zainstaluj poprawkę w ciągu N dni” zakłada, że poprawka istnieje i że wystarczy okno serwisowe. Tu dla linii 9 zamknięciem jest wdrożenie innego produktu. W praktyce:

• Rozdziel dwa findingi. Jeden dla CVE (ryzyko techniczne, krytyczne), drugi dla stanu „wersja bez ścieżki poprawek” (ryzyko cyklu życia). Pierwszy zamyka migracja, ale drugi powinien zostać w rejestrze także po niej, jako kontrola, że kolejna linia nie zostanie znowu zapomniana. Ten wzorzec opisywałem przy EOL jako findingu samym w sobie.
• Inny SLA, ten sam priorytet. Migracji nie zrobi się w 7 dni jak aktualizacji. Ustal realny termin z właścicielem, a do tego czasu zapisz kompensację (ograniczenie dostępu) z datą weryfikacji. Bez tego finding po prostu przekroczy SLA i zostanie wyjątkiem bez końca.
• Nie zamykaj po aktualizacji linii 10 do 10-202608. Wydanie z linii 10 wciąż może być podatne. Warunek zamknięcia to 10-202609 lub nowsze, a nie „przeszliśmy na nową nazwę”.

Podobny układ, czyli poprawkę tylko dla nowszych gałęzi, Cisco miało we wrześniu przy ISE, gdzie dla 3.1 i 3.2 nie było fixa. Hardening release coraz częściej oznacza więc nie tylko „zaktualizuj”, ale też „ta linia się skończyła”.

Co powinien zrobić VE

(1) Wyszukaj w CMDB, skanerze i rejestrze licencji obie nazwy: Cisco License On-Prem i Smart Software Manager / SSM On-Prem. Sprawdź też, gdzie urządzenia sieciowe zgłaszają użycie licencji. (2) Dla każdej instancji zapisz pełną wersję i linię. (3) Linia 10: aktualizacja do 10-202609 w normalnym trybie dla krytycznych. (4) Linia 9 i starsze: finding migracji z właścicielem, terminem i zapisaną kompensacją sieciową do czasu zakończenia. (5) Przeczytaj release notes 10-202609 przed szacowaniem pracy. (6) Obserwuj advisory: jest w wersji 1.0, a stan „nieznane wykorzystanie” może się zmienić.

Powiązane na blogu

• Jedno CVE, wiele luk — jak Cisco grupuje podatności według CWE
• Cisco ISE, hardening wrzesień 2026 — brak fixa dla 3.1/3.2
• Kiedy EOL powinien być findingiem — cykl życia jako osobne ryzyko
• Proxmox VE: „nowa stara” podatność — CVE dla wydań, które są już EOL

Źródła

• Cisco PSIRT — Cisco License (Smart Software Manager) On-Prem Security Hardening Release: October 2026 (cisco-sa-hardening-ssm-Ph77wdhf, 7.10.2026) — sec.cloudapps.cisco.com
• Cisco — Cisco License On-Prem 10-202609 Release Notes (PDF, wskazany w advisory jako źródło kroków migracji; nieodczytany) — cisco.com
• NVD — CVE-2026-76480 — nvd.nist.gov
• NVD — CVE-2026-76482 — nvd.nist.gov
• NVD — CVE-2026-76483 — nvd.nist.gov
• NVD — CVE-2026-76484 — nvd.nist.gov
• CISA Known Exploited Vulnerabilities Catalog (stan 2026.10.16: żadne z czterech CVE nie jest wpisane) — cisa.gov

Nota redakcyjna: stan informacji 18 października 2026. Zakres, tabela poprawek, brak obejść i status wykorzystania pochodzą z advisory Cisco w wersji 1.0. Wektory CVSS i oceny SSVC pochodzą z rekordów NVD (status „Awaiting Analysis”, wektory od Cisco PSIRT). Release notes 10-202609 nie udało się odczytać, więc tekst nie opisuje kroków migracji z linii 9. Ograniczenie dostępu sieciowego jako kompensacja i podział na dwa findingi to wnioski autora, nie zalecenia Cisco. Przed decyzją sprawdź aktualną wersję advisory.