SBOM i modelowanie zagrożeń w odniesieniu do wyrobów medycznych
Sytance · Zaktualizowano
SBOM i model zagrożeń odpowiadają na różne pytania. SBOM identyfikuje komponenty oprogramowania i relacje zależności. Model zagrożeń wyjaśnia, w jaki sposób wyrób, system oprogramowania, użytkownik, środowisko lub ścieżka aktualizacji mogą stać się celem ataku oraz jak atak ten może wpłynąć na bezpieczeństwo, działanie lub ochronę.
Różne zapisy
Podatność komponentu staje się kwestią dotyczącą konkretnego wyrobu, gdy znana jest rola komponentu. Parser sieciowy może bezpośrednio odbierać niezaufane dane wejściowe; ta sama biblioteka skompilowana bez podatnej funkcji może wiązać się z innym narażeniem. SBOM identyfikuje komponent, a model zagrożeń dostarcza architektury potrzebnej do zbadania tej różnicy.
NTIA definiuje SBOM jako odczytywalny maszynowo wykaz komponentów oprogramowania i ich powiązań. W ocenie wyrobu pomaga to ustalić, jakie oprogramowanie jest w nim obecne oraz gdzie szukać informacji od dostawcy lub o podatnościach.
SBOM
Rejestruje nazwy komponentów, dostawców, wersje, identyfikatory, skróty, zależności i informacje o autorstwie, aby producent i klient mogli śledzić narażenie związane z komponentami i status ich wsparcia.
Model zagrożeń
Rejestruje zasoby, podmioty, granice zaufania, przepływy danych, interfejsy, ścieżki ataku, zagrożenia, środki ograniczające, założenia i decyzje dotyczące ryzyka resztkowego.
Architektura bezpieczeństwa
Pokazuje, jak środki kontroli, takie jak uwierzytelnianie, autoryzacja, szyfrowanie, rejestrowanie zdarzeń, ochrona aktualizacji i odzyskiwanie, są rozmieszczone w systemie i powiązanych usługach.
Zarządzanie ryzykiem
Określa, czy pozostałe ryzyko jest akceptowalne oraz jak ustalenia dotyczące cyberbezpieczeństwa wpływają na bezpieczeństwo, działanie, oznakowanie, nadzór po wprowadzeniu do obrotu i działania naprawcze.
Powiązanie przed wprowadzeniem do obrotu
Aktualne wytyczne FDA dotyczące etapu przedrynkowego oczekują, że dowody z SBOM, modelowania zagrożeń, oceny ryzyka cyberbezpieczeństwa, architektury i testów będą ze sobą powiązane. W przypadku wyrobu cybernetycznego z sekcji 524B SBOM jest ustawowym elementem zgłoszenia i musi obejmować komercyjne, otwarte i gotowe komponenty oprogramowania.
- Model zagrożeń powinien obejmować system wyrobu, podmioty zewnętrzne, wdrożenie, interoperacyjność, utrzymanie, aktualizacje, założenia dotyczące łańcucha dostaw i wycofanie z eksploatacji.
- SBOM powinien obejmować komponenty opracowane przez producenta i strony trzecie, zależności dalszych poziomów, status wsparcia i informacje potrzebne do oceny znanych podatności.
- Widoki architektury powinny wyjaśniać interfejsy, protokoły, granice zaufania, użytkowników, środki kontroli, powiązane systemy i ścieżki aktualizacji.
- Testy powinny wykazać skuteczność wybranych środków kontroli bezpieczeństwa i ograniczania zagrożeń, w tym testów podatności i testów penetracyjnych, gdy są istotne.
Pozycja komponentu z SBOM powinna być identyfikowalna w architekturze i w powiązanej analizie podatności. Takie powiązania łączą wykaz z modelowaniem zagrożeń, testami, oznakowaniem i zarządzaniem po wprowadzeniu do obrotu.
Powiązanie po wprowadzeniu do obrotu
Po wprowadzeniu do obrotu SBOM i model zagrożeń stają się zapisami operacyjnymi. SBOM pomaga identyfikować narażenie po zmianie u dostawcy, w pakiecie open source, komponencie komercyjnym lub zależności systemu operacyjnego. Model zagrożeń pomaga ustalić, czy takie narażenie może doprowadzić do szkody u pacjenta w rzeczywistej architekturze i środowisku użytkowania wyrobu.
Należy sprawdzić, czy podatna wersja i kod występują w wyrobie, a następnie ustalić, w jaki sposób atakujący mógłby do nich dotrzeć. Należy ocenić istniejące środki kontroli i możliwą szkodę u pacjentów. Wynik dotyczy ocenionych konfiguracji; wersje nadal używane mogą wymagać osobnej oceny.
Model zagrożeń należy aktualizować, gdy nowa podatność, nowa technika ataku, zmiana założeń dotyczących wdrożenia, nowy interfejs lub usługa chmurowa albo zmieniona ścieżka aktualizacji zmieniają obraz ryzyka.
Vulnerability Exploitability eXchange (VEX) przekazuje ocenę wpływu określonej podatności na konkretny produkt. Należy wskazać objętą oceną wersję i konfigurację oraz wyjaśnić wszelkie warunki, które odbiorca musi utrzymać. Jeśli potrzebne jest działanie naprawcze, należy określić dostępną dla użytkownika aktualizację lub inne działanie.
Utrzymywanie użytecznych zapisów
SBOM i model zagrożeń powinny wskazywać opisywaną wersję produktu i pozostać aktualne po jego wprowadzeniu do obrotu. SBOM musi być również dostępny w formacie odczytywalnym maszynowo. Oba zapisy należy powiązać z dokumentacją zarządzania ryzykiem.
Podstawowy zakres określony przez NTIA w 2021 r. obejmuje takie elementy danych jak nazwa dostawcy, nazwa komponentu, oznaczenie wersji, identyfikator komponentu, relacja zależności, imię i nazwisko autora oraz znacznik czasu. FDA dodaje oczekiwania właściwe dla wyrobu, takie jak status wsparcia oprogramowania, znane podatności i powiązanie ze środkami kontroli ryzyka dotyczącego wyrobu.
Model powinien wyjaśniać, jak atakujący może dotrzeć do funkcji wyrobu i jakie zabezpieczenie zapobiega takiemu działaniu lub je ogranicza. Należy opisać wyrób i połączone systemy, a następnie powiązać każdy scenariusz ataku z jego warunkami, wybranymi środkami kontroli i pozostałym ryzykiem.
- Nawet wyrób działający offline może otrzymać złośliwe dane wejściowe przez interfejs aktualizacji lub konserwacji. Należy uwzględnić takie ścieżki w modelu zagrożeń.
- SBOM bez znanych krytycznych CVE niewiele mówi o błędach projektowych lub braku kontroli dostępu. Takie zagrożenia należy oceniać w odniesieniu do architektury.
- Raport z testów penetracyjnych dotyczy określonego w nim zakresu i konfiguracji. Wyniki należy wykorzystywać wraz z analizą projektu i planowanymi środkami utrzymania.
- Jeśli ochrona zależy od sieci klienta, należy określić wymagane środki kontroli i sprawdzić, czy odpowiadają one zagrożeniu. Trzeba poinformować o warunkach, które klient powinien utrzymać.
Źródła
- FDA, wytyczne dotyczące cyberbezpieczeństwa przed wprowadzeniem do obrotu, luty 2026 r.
- FDA, wytyczne dotyczące cyberbezpieczeństwa po wprowadzeniu do obrotu, grudzień 2016 r.
- NTIA, Framing Software Component Transparency: Establishing a Common Software Bill of Materials
- MITRE, Playbook for Threat Modeling Medical Devices