Modelowanie zagrożeń dla sterowników

Autorzy sterowników i architekci powinni uczynić modelowanie zagrożeń integralną częścią procesu projektowania dla każdego sterownika. Ten temat zawiera wskazówki dotyczące tworzenia modeli zagrożeń dla sterowników systemu Windows.

Zabezpieczenia powinny być podstawowym punktem projektowania dla każdego sterownika. Każdy udany produkt jest celem. Jeśli piszesz sterownik dla systemu Windows, musisz założyć, że czasami, gdzieś, ktoś spróbuje użyć sterownika w celu naruszenia zabezpieczeń systemu.

Projektowanie bezpiecznego sterownika obejmuje:

• Identyfikowanie punktów, w których kierowca może być narażony na atak.
• Analizowanie typów ataków, które mogą być instalowane w każdym takim momencie.
• Zapewnienie, że kierowca został zaprojektowany w taki sposób, aby udaremnić takie ataki.

Modelowanie zagrożeń to ustrukturyzowane podejście do tych ważnych zadań projektowych. Model zagrożeń to sposób kategoryzowania i analizowania zagrożeń dla zasobu. Z perspektywy twórcy sterowników zasoby to sprzęt, oprogramowanie i dane na komputerze lub w sieci.

Model zagrożeń odpowiada na następujące pytania:

• Które zasoby wymagają ochrony?
• Jakie zagrożenia są narażone na zasoby?
• Jak ważne lub prawdopodobne jest każde zagrożenie?
• Jak można wyeliminować zagrożenia?

Modelowanie zagrożeń jest ważną częścią projektowania oprogramowania, ponieważ gwarantuje, że zabezpieczenia są wbudowane w produkt, a nie dodawane później jako wtórna refleksja. Dobry model zagrożeń może pomóc znaleźć i zapobiec usterce podczas procesu projektowania, eliminując potencjalnie kosztowne poprawki później i ewentualne szkody reputacji organizacji.

Ta sekcja stosuje zasady modelowania zagrożeń do projektowania sterownika i zawiera przykłady zagrożeń, na które sterownik może być podatny. Aby uzyskać bardziej szczegółowy opis modelowania zagrożeń dla projektowania oprogramowania, zapoznaj się z tymi zasobami.

• Witryna sieci Web SDL firmy Microsoft:

  https://www.microsoft.com/sdl

• Uproszczona implementacja języka Microsoft SDL:

  Pobierz oficjalny dokument

• W tym wpisie w blogu opisano sposób pobierania bezpłatnej kopii cyklu życia programowania zabezpieczeń: SDL, autorstwa Michaela Howarda i Steve'a Lipnera:

  https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/

Tworzenie modeli zagrożeń dla sterowników

Utworzenie modelu zagrożeń wymaga dokładnego zrozumienia projektu kierowcy, typów zagrożeń, na które może zostać narażony sterownik, oraz konsekwencji ataku zabezpieczeń wykorzystującego określone zagrożenie. Po utworzeniu modelu zagrożenia dla sterownika można określić, jak ograniczyć potencjalne zagrożenia.

Modelowanie zagrożeń jest najbardziej skuteczne, gdy jest wykonywane w zorganizowany, ustrukturyzowany sposób podczas projektowania sterowników, a nie przypadkowo podczas kodowania. Podejście ustrukturyzowane zwiększa prawdopodobieństwo wykrycia luk w zabezpieczeniach w projekcie, co pomaga zapewnić, że model jest kompleksowy.

Jednym ze sposobów organizowania wysiłków związanych z modelowaniem zagrożeń jest wykonanie następujących kroków:

1. Utwórz diagram ustrukturyzowany przedstawiający przepływ danych przez sterownik. Uwzględnij wszystkie możliwe zadania wykonywane przez sterownik oraz źródło i miejsce docelowe wszystkich danych wejściowych i wyjściowych sterownika. Formalny diagram przepływu danych lub podobny diagram ustrukturyzowany może pomóc w analizie ścieżki danych za pośrednictwem sterownika i zidentyfikowaniu zewnętrznych interfejsów, granic i interakcji sterownika.
2. Przeanalizuj potencjalne zagrożenia bezpieczeństwa na podstawie diagramu przepływu danych.
3. Oceń zagrożenia zidentyfikowane w poprzednim kroku i określ, jak je ograniczyć.

Tworzenie diagramu przepływu danych

Diagram przepływu danych przedstawia w formie koncepcyjnej przepływ danych między sterownikiem a jednostkami zewnętrznymi, z którymi współdziała — zazwyczaj system operacyjny, proces użytkownika i urządzenie. Formalny diagram przepływu danych używa następujących symboli:

Na poniższej ilustracji przedstawiono przykładowy diagram przepływu danych dla hipotetycznego sterownika modelu WDM w trybie jądra dla systemu Windows. Niezależnie od architektury określonego typu sterownika, model koncepcyjny jest taki sam: pokaż wszystkie ścieżki danych i zidentyfikuj każde źródło danych, które wprowadza lub zamyka sterownik.

Uwaga Na poprzedniej ilustracji przedstawiono dane przepływające bezpośrednio między procesem użytkownika a sterownikiem i pomija wszelkie sterowniki pośrednie. Jednak w rzeczywistości wszystkie żądania przechodzą przez menedżera we/wy i mogą przechodzić przez co najmniej jeden sterownik wyższego poziomu przed dotarciem do określonego sterownika. Rysunek pomija te pośrednie kroki, aby podkreślić znaczenie oryginalnego źródła danych i kontekstu wątku, który dostarczył dane. Sterowniki trybu jądra muszą weryfikować dane pochodzące z trybu użytkownika.

Informacje są wprowadzane do sterownika dzięki żądaniom z systemu operacyjnego, żądaniom z procesu użytkownika lub żądaniom (zazwyczaj przerwań) z urządzenia.

Sterownik na poprzedniej ilustracji odbiera dane z systemu operacyjnego w kilku typach żądań:

• Żądania wykonywania zadań administracyjnych dla sterownika i jego urządzenia za pośrednictwem wywołań do procedur DriverEntry, DriverUnload i AddDevice
• Żądania Plug and Play (IRP_MJ_PNP)
• Żądania zarządzania energią (IRP_MJ_POWER)
• Wewnętrzne żądania sterowania we/wy urządzenia (IRP_MJ_INTERNAL_DEVICE_CONTROL)

W odpowiedzi na te żądania dane przepływa z sterownika z powrotem do systemu operacyjnego jako informacje o stanie. Sterownik na rysunku odbiera dane z procesu użytkownika w następujących typach żądań:

• Tworzenie, odczytywanie i zapisywanie żądań (IRP_MJ_CREATE, IRP_MJ_READ lub IRP_MJ_WRITE)
• Żądania sterowania we/wy urządzeń publicznych (IRP_MJ_DEVICE_ CONTROL)

W odpowiedzi na te żądania dane wyjściowe oraz informacje o stanie przepływają ze sterownika z powrotem do procesu użytkownika.

Na koniec sterownik odbiera dane z urządzenia z powodu operacji we/wy urządzenia lub akcji użytkownika (takich jak otwieranie zasobnika na stacji dysków CD), które zmieniają stan urządzenia. Podobnie dane od kierowcy przepływają do urządzenia podczas operacji wejścia/wyjścia i zmiany statusu urządzenia.

Na poprzedniej ilustracji przedstawiono przepływ danych sterowników na szerokim poziomie koncepcyjnym. Każdy okrąg reprezentuje stosunkowo duże zadanie i nie zawiera szczegółów. W niektórych przypadkach diagram jeden poziom, taki jak przykład, jest odpowiedni do zrozumienia źródeł danych i ścieżek. Jeśli sterownik obsługuje wiele różnych typów żądań we/wy z różnych źródeł, może być konieczne utworzenie co najmniej jednego dodatkowego diagramu, który pokazuje więcej szczegółów. Na przykład okrąg oznaczony etykietą "Obsługa żądań we/wy" może zostać rozszerzony na oddzielny diagram, podobnie jak na poniższej ilustracji.

Drugi diagram przedstawia oddzielne zadania dla każdego typu żądania we/wy w pierwszym diagramie. (Dla uproszczenia pominięto ścieżki danych do urządzenia).

Jednostki zewnętrzne i typy danych wejściowych i wyjściowych pokazanych na diagramie mogą się różnić w zależności od typu urządzenia. Na przykład system Windows dostarcza sterowniki klas dla wielu typów typowych urządzeń. Sterownik klasy dostarczonej przez system współpracuje z minidriver dostarczanym przez dostawcę, który zazwyczaj jest biblioteką linków dynamicznych (DLL), która zawiera zestaw procedur wywołania zwrotnego. Żądania we/wy użytkownika są kierowane do sterownika klasy, który następnie wywołuje procedury w ramach mini-sterownika w celu wykonania określonych zadań. Minidriver zwykle nie odbiera całego pakietu żądania we/wy jako danych wejściowych; Zamiast tego każda rutyna wywołania zwrotnego odbiera tylko dane wymagane dla określonego zadania.

Podczas tworzenia diagramów przepływu danych należy pamiętać o różnych źródłach żądań sterowników. Każdy kod uruchomiony na komputerze użytkownika może wygenerować żądanie wejścia/wyjścia do sterownika, począwszy od znanych aplikacji, takich jak Microsoft Office, poprzez freeware i shareware, a skończywszy na pobraniach internetowych pochodzących z potencjalnie wątpliwych źródeł. W zależności od konkretnego urządzenia może być również konieczne rozważenie koderów multimedialnych lub filtrów innych firm dostarczanych przez firmę w celu obsługi jego urządzenia. Możliwe źródła danych obejmują:

• IRP_MJ_XXX żąda, aby sterownik obsłużył
• IOCTLs definiowane lub obsługiwane przez sterownik
• Interfejsy API, które sterownik wywołuje
• Procedury wywołania zwrotnego
• Wszystkie inne interfejsy udostępniane przez sterownik
• Pliki, które sterownik odczytuje lub zapisuje, w tym pliki używane podczas instalacji
• Klucze rejestru, które sterownik odczytuje lub zapisuje
• Strony właściwości konfiguracji i wszelkie inne informacje udostępniane przez użytkownika, z których korzysta sterownik

Model powinien również obejmować procedury instalacji i aktualizacji sterowników. Uwzględnij wszystkie pliki, katalogi i wpisy rejestru, które są odczytywane lub zapisywane podczas instalacji sterownika. Należy również wziąć pod uwagę interfejsy uwidocznione w instalatorach urządzeń, współinstalatorach i stronach właściwości.

Każdy punkt, w którym sterownik wymienia dane z jednostką zewnętrzną, jest potencjalnie podatny na ataki.

Analizowanie potencjalnych zagrożeń

Po zidentyfikowaniu punktów, w których kierowca może być narażony na zagrożenia, można określić, które typy zagrożeń mogą wystąpić w każdym punkcie. Rozważ następujące typy pytań:

• Jakie mechanizmy zabezpieczeń są na miejscu w celu ochrony każdego zasobu?
• Czy wszystkie przejścia i interfejsy są prawidłowo zabezpieczone?
• Czy niewłaściwe użycie funkcji może nieumyślnie naruszyć bezpieczeństwo?
• Czy złośliwe użycie funkcji może zagrozić bezpieczeństwu?
• Czy ustawienia domyślne zapewniają odpowiednie zabezpieczenia?

Podejście STRIDE do kategoryzacji zagrożeń

Skrót STRIDE opisuje sześć kategorii zagrożeń dla oprogramowania. Ten akronim pochodzi z:

• Spoofing
• Amperowanie T
• Repudiation (Odrzucenie)
• Ujawnienie informacji
• Odmowa usługi
• Podniesienie uprawnień

Korzystając z metody STRIDE jako przewodnika, możesz podać szczegółowe pytania dotyczące rodzajów ataków, które mogą być ukierunkowane na kierowcę. Celem jest określenie typów ataków, które mogą być możliwe w każdym punkcie podatnym na zagrożenia w kierowcy, a następnie utworzenie scenariusza dla każdego możliwego ataku.

• Fałszowanie używa poświadczeń innej osoby w celu uzyskania dostępu do w inny sposób niedostępnych zasobów. Proces instaluje atak fałszujący, przekazując sfałszowane lub skradzione poświadczenia.

• Manipulowanie polega na zmianie danych w celu przeprowadzenia ataku. Na przykład sterownik może być podatny na manipulowanie, jeśli wymagane pliki sterowników nie są odpowiednio chronione przez listy podpisywania sterowników i kontroli dostępu (ACL). W takiej sytuacji złośliwy użytkownik może zmienić pliki, co narusza bezpieczeństwo systemu.

• Odrzucenie występuje, gdy użytkownik zaprzecza wykonaniu działania, ale cel działania nie ma możliwości wykazania inaczej. Sterownik może być podatny na zagrożenie odrzucenia, jeśli nie rejestruje akcji, które mogłyby naruszyć bezpieczeństwo. Na przykład sterownik urządzenia wideo może być podatny na odrzucenie, jeśli nie rejestruje żądań zmiany właściwości urządzenia, takich jak fokus, zeskanowany obszar, częstotliwość przechwytywania obrazów, lokalizacja docelowa przechwyconych obrazów itd. Wynikowe obrazy mogą być uszkodzone, ale administratorzy systemu nie mieliby możliwości określenia, który użytkownik spowodował problem.

• Zagrożenia dotyczące ujawniania informacji są dokładnie tak samo jak nazwa: ujawnienie informacji użytkownikowi, który nie ma uprawnień do ich wyświetlania. Każdy sterownik przekazujący informacje do lub z buforu użytkownika jest podatny na zagrożenia związane z ujawnieniem informacji. Aby uniknąć zagrożeń związanych z ujawnieniem informacji, sterowniki muszą zweryfikować długość każdego buforu użytkownika oraz zainicjować bufory zerami przed zapisaniem danych.

• Ataki typu "odmowa usługi " zagrażają możliwości dostępu do zasobów przez prawidłowych użytkowników. Zasoby mogą być miejscem na dysku, połączeniami sieciowymi lub urządzeniem fizycznym. Ataki, które spowalniają wydajność na niedopuszczalne poziomy, są również uznawane za ataki typu "odmowa usługi". Sterownik, który pozwala użytkownikowi na niepotrzebną monopolizację zasobu systemowego, może być podatny na atak typu "odmowa usługi", jeśli użycie zasobów utrudnia innym prawidłowym użytkownikom wykonywanie swoich zadań.

  Na przykład sterownik może używać semafora do ochrony struktury danych podczas wykonywania na poziomie IRQL = PASSIVE_LEVEL. Jednak sterownik musi uzyskać i zwolnić semafor w ramach pary KeEnterCriticalRegion/KeLeaveCriticalRegion, która wyłącza dostarczanie wywołań procedur asynchronicznych (APC) oraz ponownie je włącza. Jeśli sterownik nie będzie używać tych procedur, APC może spowodować, że system operacyjny zawiesić wątek, który zawiera semafor. W związku z tym inne procesy (w tym utworzone przez administratora) nie będą mogły uzyskać dostępu do struktury.

• Atak z podwyższonym poziomem uprawnień może wystąpić, jeśli nieuprzywilejowany użytkownik uzyska stan uprzywilejowany. Sterownik trybu jądra, który przekazuje dojście trybu użytkownika do procedury ZwXxx , jest narażony na ataki z podwyższonym poziomem uprawnień, ponieważ procedury ZwXxx pomijają kontrole zabezpieczeń. Sterowniki trybu jądra muszą weryfikować wszystkie dojścia odbierane z wywołań trybu użytkownika.

  Ataki podniesienia uprawnień mogą również wystąpić, jeśli sterownik trybu jądra opiera się na wartości RequestorMode w nagłówku IRP w celu określenia, czy żądanie we/wy pochodzi z wywołującego trybu jądra lub trybu użytkownika. W IRP-ach pochodzących z sieci lub usługi serwera (SRVSVC) wartość RequestorMode jest ustawiona na KernelMode, niezależnie od źródła żądania. Aby uniknąć takich ataków, kierowcy muszą przeprowadzać kontrole kontroli dostępu dla takich żądań zamiast po prostu używać wartości RequestorMode.

Techniki analizy sterowników

Prostym sposobem organizowania analizy jest wyświetlenie listy obszarów podatnych na zagrożenia wraz z potencjalnymi zagrożeniami i co najmniej jednym scenariuszem dla każdego typu zagrożenia.

Aby przeprowadzić dokładną analizę, należy zbadać możliwość zagrożeń w każdym potencjalnie podatnym punkcie sterownika. W każdym punkcie podatnym na zagrożenia określ każdą kategorię zagrożeń (fałszowanie, manipulowanie, odrzucanie, ujawnianie informacji, odmowa usługi i podniesienie uprawnień), które mogą być możliwe. Następnie utwórz co najmniej jeden scenariusz ataku dla każdego wiarygodnego zagrożenia.

Rozważmy na przykład przepływ danych dla żądań IRP_MJ_DEVICE_CONTROL, jak pokazano na powyższej ilustracji. W poniższej tabeli przedstawiono dwa typy zagrożeń, które może napotkać sterownik podczas przetwarzania takich żądań:

Drzewa zagrożeń i konspekcje mogą być przydatne w modelowaniu takich złożonych scenariuszy.

Drzewo zagrożeń to diagram przedstawiający hierarchię zagrożeń lub luk w zabezpieczeniach; w istocie drzewo zagrożeń naśladuje kroki złośliwego użytkownika podczas instalowania ataku. Ostatecznym celem ataku jest szczyt hierarchii. Każdy poziom podrzędny pokazuje kroki wymagane do przeprowadzenia ataku. Na poniższej ilustracji przedstawiono proste drzewo zagrożeń dla scenariusza odmowy usługi w poprzednim przykładzie.

Drzewo zagrożeń przedstawia kroki wymagane do zainstalowania określonego ataku i relacji między krokami. Konspekt jest alternatywą dla drzewa zagrożeń.

Zarys po prostu wymienia w hierarchicznej kolejności kroki podejmowane w celu zaatakowania określonego zagrożenia. Przykład:

1.0 Spowodowanie, że urządzenie przestanie odpowiadać.

1.1 Wydać IOCTLS w sekwencji błędów.

1.1.1 Ustal sekwencję, która powoduje niepowodzenie urządzenia.

1.1.2 Uzyskaj podwyższone uprawnienia, aby wydawać wewnętrzne IOCTL.

Każda z technik może pomóc zrozumieć, które zagrożenia są najbardziej niebezpieczne i które luki w projekcie są najbardziej krytyczne.

Szybkie modelowanie zagrożeń ścieżek

Jeśli zasoby są ograniczone, zamiast tworzyć kompletny diagram modelu zagrożeń, można utworzyć podsumowanie konspektu, aby pomóc ocenić zagrożenia bezpieczeństwa dla sterownika. Na przykład poniższy tekst opisuje niektóre obszary powierzchni przedstawione w przykładowym sterowniku opisanym w poprzednim przykładzie.

Sterownik odbiera dane z systemu operacyjnego w kilku typach żądań:

• Żądania wykonywania zadań administracyjnych dla sterownika i jego urządzenia za pośrednictwem wywołań do procedur DriverEntry, DriverUnload i AddDevice
• Żądania Plug and Play (IRP_MJ_PNP)
• Żądania zarządzania energią (IRP_MJ_POWER)
• Wewnętrzne żądania sterowania we/wy urządzenia (IRP_MJ_INTERNAL_DEVICE_CONTROL)

W odpowiedzi na te żądania dane przepływa z sterownika z powrotem do systemu operacyjnego jako informacje o stanie. Sterownik odbiera dane z procesu użytkownika w następujących typach żądań:

• Tworzenie, odczytywanie i zapisywanie żądań (IRP_MJ_CREATE, IRP_MJ_READ lub IRP_MJ_WRITE)
• Żądania sterowania we/wy urządzeń publicznych (IRP_MJ_DEVICE_ CONTROL)

W odpowiedzi na te żądania dane wyjściowe oraz informacje o stanie przepływają ze sterownika z powrotem do procesu użytkownika.

Korzystając z tej podstawowej wiedzy na temat przepływu danych do sterownika, możesz zbadać każdy obszar danych wejściowych i wyjściowych pod kątem możliwych zagrożeń.

Podejście DREAD do oceny zagrożeń

Określenie, jak i gdzie może zostać zaatakowany kierowca, nie wystarczy. Następnie należy ocenić te potencjalne zagrożenia, określić ich względne priorytety i opracować strategię ograniczania ryzyka.

DREAD to skrót opisujący pięć kryteriów oceny zagrożeń dla oprogramowania. DREAD oznacza:

• Damage
• Reprodukowalność języka R
• Eksploatacyjność
• Zainfekowani użytkownicy
• Odkrywalność D

Aby określić priorytety zagrożeń dla kierowcy, należy sklasyfikować każde zagrożenie z zakresu od 1 do 10 na wszystkich 5 kryteriów oceny DREAD, a następnie dodać oceny i podzielić przez 5 (liczbę kryteriów). Wynik jest wynikiem liczbowym z zakresu od 1 do 10 dla każdego zagrożenia. Wysokie wyniki wskazują na poważne zagrożenia.

• Uszkodzenie. Ocena szkód, które mogą wynikać z ataku bezpieczeństwa, jest oczywiście krytyczną częścią modelowania zagrożeń. Uszkodzenie może obejmować utratę danych, awarię sprzętu lub nośnika, wydajność podrzędną lub dowolną podobną miarę, która ma zastosowanie do urządzenia i jego środowiska operacyjnego.

• Powtarzalność to miara częstotliwości pomyślnego ataku określonego typu. Łatwo odtwarzalne zagrożenie jest bardziej prawdopodobne, aby zostać wykorzystane niż luka w zabezpieczeniach, która występuje rzadko lub nieprzewidywalnie. Na przykład zagrożenia dla funkcji, które są instalowane domyślnie lub są używane w każdej potencjalnej ścieżce kodu, są wysoce powtarzalne.

• Możliwość wykorzystania ocenia nakład pracy i wiedzę wymaganą do zainstalowania ataku. Zagrożenie, które może zostać zaatakowane przez stosunkowo niedoświadczonego studenta uczelni, jest wysoce wykorzystywane. Atak, który wymaga wysoko wykwalifikowanych pracowników i jest kosztowny do przeprowadzenia, jest mniej możliwy do wykorzystania.

  W ocenie możliwości wykorzystania należy również rozważyć liczbę potencjalnych osób atakujących. Zagrożenie, które może być wykorzystywane przez dowolnego zdalnego, anonimowego użytkownika, jest bardziej możliwe do wykorzystania niż to, które wymaga lokalnego, wysoce autoryzowanego użytkownika.

• Użytkownicy, których dotyczy problem. Liczba użytkowników, których może dotyczyć atak, jest kolejnym ważnym czynnikiem w ocenie zagrożenia. Atak, który może mieć wpływ na co najwyżej jednego lub dwóch użytkowników, byłby oceniony stosunkowo nisko w tej skali. Z drugiej strony atak typu "odmowa usługi", który powoduje awarię serwera sieciowego, może mieć wpływ na tysiące użytkowników i z tego powodu będzie oceniony znacznie wyżej.

• Możliwość odnajdywania to prawdopodobieństwo wykorzystania zagrożenia. Łatwość odnajdywania jest trudna do dokładnego oszacowania. Najbezpieczniejszym podejściem jest założenie, że każda luka w zabezpieczeniach zostanie ostatecznie wykorzystana i zatem polegać na innych środkach w celu ustalenia względnego rankingu zagrożenia.

Przykład: ocenianie zagrożeń przy użyciu elementu DREAD

Kontynuując powyższy przykład, w poniższej tabeli pokazano, jak projektant może ocenić hipotetyczny atak typu "odmowa usługi":

Ograniczanie zagrożeń

Projekt sterownika powinien łagodzić wszystkie zagrożenia, które uwidacznia model. Jednak w niektórych przypadkach środki zaradcze mogą nie być praktyczne. Rozważmy na przykład atak, który potencjalnie wpływa na bardzo niewielu użytkowników i prawdopodobnie nie spowoduje utraty danych lub użyteczności systemu. Jeśli ograniczenie takiego zagrożenia wymaga kilku miesięcy dodatkowej pracy, rozsądnym byłoby poświęcić dodatkowy czas na testowanie sterownika. Należy jednak pamiętać, że w końcu złośliwy użytkownik prawdopodobnie znajdzie lukę w zabezpieczeniach i zainstaluje atak, a następnie sterownik będzie wymagał poprawki problemu.

Uwzględnianie modelowania zagrożeń w szerszym procesie cyklu życia tworzenia zabezpieczeń

Rozważ uwzględnienie procesu modelowania zagrożeń w szerszym cyklu życia bezpiecznego programowania — SDL.

Proces SDL firmy Microsoft zawiera szereg zalecanych procesów tworzenia oprogramowania, który można zmodyfikować w celu dopasowania do dowolnego rozmiaru organizacji — w tym jednego dewelopera. Rozważ dodanie składników zaleceń SDL do procesu tworzenia oprogramowania.

Aby uzyskać więcej informacji, zobacz Microsoft Security Development Lifecycle (SDL) — wskazówki dotyczące procesu.

Szkolenia i możliwości organizacyjne — kontynuuj szkolenie w zakresie zabezpieczeń tworzenia oprogramowania, aby zwiększyć możliwość rozpoznawania i korygowania luk w zabezpieczeniach oprogramowania.

Firma Microsoft udostępnia do pobrania cztery podstawowe klasy szkoleniowe SDL. Podstawowe kursy szkoleniowe cyklu życia zabezpieczeń firmy Microsoft

Aby uzyskać bardziej szczegółowe informacje na temat trenowania języka SDL, zobacz ten oficjalny dokument. Podstawowe szkolenia dotyczące zabezpieczeń oprogramowania dla języka Microsoft SDL

Wymagania i projektowanie — najlepszą okazją do utworzenia zaufanego oprogramowania jest wstępne planowanie nowego wydania lub nowej wersji, ponieważ zespoły programistyczne mogą identyfikować kluczowe obiekty i integrować zabezpieczenia i prywatność, co minimalizuje zakłócenia w planach i harmonogramach.

Kluczowymi danymi wyjściowymi w tej fazie jest ustawienie określonych celów zabezpieczeń. Na przykład podjęcie decyzji, że cały twój kod powinien przejść analizę kodu w Visual Studio według wszystkich reguł, bez żadnych ostrzeżeń.

Implementacja — wszystkie zespoły programistyczne powinny definiować i publikować listę zatwierdzonych narzędzi oraz skojarzonych z nimi kontroli zabezpieczeń, takich jak opcje kompilatora/konsolidatora i ostrzeżenia.

Dla programisty sterowników większość użytecznych prac jest wykonywana w tej fazie. W miarę pisania kodu jest on sprawdzany pod kątem możliwej słabości. Narzędzia, takie jak analiza kodu i weryfikator sterowników, służą do wyszukiwania obszarów w kodzie, które mogą być wzmocnione.

Weryfikacja — weryfikacja to punkt, w którym oprogramowanie jest funkcjonalnie ukończone i jest testowane pod kątem celów zabezpieczeń określonych w fazie wymagań i projektowania.

Dodatkowe narzędzia, takie jak binscope i testy fuzzujące, mogą służyć do weryfikacji, czy cele zabezpieczeń w zakresie projektowania zostały osiągnięte, a kod jest gotowy do wysłania.

Wydanie i odpowiedź — w ramach przygotowań do wydania produktu pożądane jest utworzenie planu reagowania na zdarzenia, który opisuje, co zrobisz, aby reagować na nowe zagrożenia i jak będziesz obsługiwać kierowcę po jego wysłaniu. Wykonanie tej pracy z wyprzedzeniem oznacza, że będzie można szybciej reagować, jeśli problemy z zabezpieczeniami zostaną zidentyfikowane w kodzie, który został wysłany.

Aby uzyskać więcej informacji na temat procesu SDL, zobacz następujące dodatkowe zasoby:

• Jest to podstawowa witryna SDL firmy Microsoft i zawiera omówienie języka SDL. https://www.microsoft.com/sdl

• W tym blogu opisano, jak pobrać bezpłatną kopię the Security Development Lifecycle: SDL, Michael Howard i Steve Lipner. https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/

• Ta strona zawiera linki do dodatkowych publikacji SDL. https://www.microsoft.com/SDL/Resources/publications.aspx

Wezwanie do działania

Dla deweloperów sterowników:

• Uczyń modelowanie zagrożeń częścią projektowania sterownika.
• Wykonaj kroki, aby skutecznie ograniczyć zagrożenia w kodzie sterownika.
• Zapoznaj się z problemami z zabezpieczeniami i niezawodnością, które mają zastosowanie do sterownika i typu urządzenia. Aby uzyskać więcej informacji, zobacz sekcje zestawu sterowników urządzeń z systemem Windows (WDK).
• Dowiedz się, jakie testy wykonują system operacyjny, menedżer operacji we/wy oraz sterowniki wyższego poziomu, zanim żądania użytkownika dotrą do Twojego sterownika — oraz jakie testy nie są wykonywane.
• Użyj narzędzi z zestawu WDK, takich jak weryfikator sterowników, aby przetestować i zweryfikować sterownik.
• Przejrzyj publiczne bazy danych znanych zagrożeń i luk w zabezpieczeniach oprogramowania.

Aby uzyskać dodatkowe zasoby zabezpieczeń sterowników, zobacz Lista kontrolna zabezpieczeń sterowników.

Zasoby zabezpieczeń oprogramowania

Książki

Pisanie bezpiecznego kodu, drugie wydanie Michael Howard i David LeBlanc

24 Śmiertelne grzechy zabezpieczeń oprogramowania: Wady programowania i Jak je naprawić, Pierwsze wydanie Michael Howard, David LeBlanc i John Viega

Sztuka oceny zabezpieczeń oprogramowania: identyfikowanie i zapobieganie lukom w zabezpieczeniach oprogramowania, autorstwa Marka Dowda, Johna McDonalda i Justina Schuha

Microsoft Hardware and Driver Developer Information

Logika anulowania w białej księdze sterowników systemu Windows

Model zabezpieczeń systemu Windows: co każdy autor sterowników musi wiedzieć

Microsoft Windows Driver Development Kit (DDK)

Zobacz Techniki programowania sterowników w architekturze sterownikówKernel-Mode

Narzędzia testowe

Zobacz Zestaw Windows Hardware Lab Kit w Teście wydajności i zgodności

Publiczne bazy danych znanych zagrożeń i luk w zabezpieczeniach oprogramowania

Aby rozwinąć wiedzę na temat zagrożeń oprogramowania, zapoznaj się z dostępnymi publicznymi bazami danych znanych zagrożeń i luk w zabezpieczeniach oprogramowania.

• Typowe luki w zabezpieczeniach i zagrożenia (CVE): https://cve.mitre.org/
• Wspólne wyliczenie słabości: https://cwe.mitre.org/
• Typowe wyliczenie i klasyfikacja wzorca ataku: https://capec.mitre.org/index.html
• NIST obsługuje witrynę opisującą sposób katalogowania luk w zabezpieczeniach: https://samate.nist.gov/BF/

Zobacz też

lista kontrolna dotycząca zabezpieczeń sterownika