Paweł Goleń, blog

Po to, by użytkownicy produktów firmy Microsoft mogli w bardziej racjonalny (oparty na większej ilości przesłanek) sposób decydować o podejmowanych akcjach.

Istnieje wiele systemów "wyceny podatności", można tu wspomnieć o systemie Common Vulnerability Scoring System, jednak często nakład pracy, który należy włożyć, by z takich systemów skorzystać jest zbyt duży, w stosunku do osiąganych korzyści.

Po co "wyceniać" podatności? Proponuję na początek przeczytać książkę Marsz ku klęsce. Znajduje się w niej dość obrazowe wytłumaczenie, dlaczego funkcje, które w założeniu ma realizować system, powinny być "wycenione", czyli powinno być jasno określone, które z funkcji są absolutnie niezbędne do działania systemu, które nie są niezbędne, ale ich brak spowoduje poważne obniżenie użyteczności systemu, jakie funkcje to typowe "fajerwerki" na zasadzie nice-to-have, a które to w zasadzie nie wiadomo po co są, ale są seksi (tm).

Czym jest podatność? Zwykle definiuje się ją jako słabość w systemie, której istnienie może doprowadzić do zrealizowania się zagrożenia. Innymi słowy intruz przeprowadza atak (akcję) która korzysta z podatności (słabości systemu) w związku z czym istniejące zagrożenie "realizuje się" (czyli "staje się faktem"). Oczywiście "mapowanie" to nie jest jeden do jeden, jedna podatność może pozwolić na realizację wielu różnych zagrożeń, wiele różnych podatności może pozwolić na realizację tego samego zagrożenia (można czynić ZŁO na więcej niż jeden sposób). Może być wreszcie tak, że do zrealizowania zagrożenia konieczne jest jednoczesne zaistnienie kilku różnych podatności. W każdym razie jednak intuicyjnie patrząc jednym z "atrybutów" podatności jest to, do czego może ona doprowadzić (co może się stać, jak złe jest to, co się stanie). Z drugiej jednak strony stopień skomplikowania wykorzystania danej podatności (stopień złożoności ataku) dla różnych podatności jest różny. To, jak bardzo złożony jest atak, wpływa bezpośrednio na to, czy dana podatność będzie wykorzystywana, a jeśli nawet będzie wykorzystywana, to jakie będą szanse na powodzenie ataku. Patrząc na te dwie kwestie, każdej z podatności można przypisać pewną wagę, która wynika wprost ze skutków oraz prawdopodobieństwa jej wykorzystania. W przypadku MS jest to Severity Rating System oraz Exploitability Index właśnie.

Nie istnieją systemy bezbłędne, więc nie istnieją również systemy pozbawione błędów bezpieczeństwa. O ile w procesie produkcji oprogramowania lub w umowie zawieranej z dostawcą, można zawrzeć warunek, że system może zostać udostępniony jeśli nie zawiera on znanych podatności (wszystkie podatności zidentyfikowane wewnętrznie oraz te wykryte przez "zewnętrzne" testy zostały usunięte i przez określony czas testów nie zostały zidentyfikowane nowe podatności), to prawdopodobnie tak się nie stanie (w sensie - produkt będzie zawierał znane podatności), bo:

• podpisana została umowa i trzeba dotrzymać terminów,
• klient sam się zgadza na używanie "dziurawej" aplikacji,

W sumie sytuację taką można porównać do tak zwanych known issues, które mimo, że istnieją, nie wstrzymują premiery produktu. Wszystko zależy tylko od tego, jak bardzo poważne są te znane problemy.

Nawet jeśli światło dzienne ujrzy aplikacja, która nie zawiera znanych podatności, to z dużym prawdopodobieństwem można zakładać, że podatności takie zostaną znalezione w przyszłości, czy to z uwagi na niedoskonałości procesu testowania (tak, proces jest niedoskonały, można go usprawniać, czynić bardziej powtarzalnym, skuteczniejszym, ale w chwili obecnej znalezienie wszystkich błędów/podatności jest po prostu niemożliwe), czy też nowe podatności zostaną wprowadzone wraz z nowymi funkcjami. Trzeba jednak gospodarować zasobami w jakiś sensowny sposób. Którą podatność naprawić najpierw, czy taką, którą wykorzystać może dowolny, anonimowy użytkownik, choć skutek wykorzystania podatności nie jest powalający, czy raczej taką, której skutek wykorzystania może być bardzo "bolesny", jednak podatność ta istnieje tylko w części dostępnej po uwierzytelnieniu, w funkcji, do której dostęp ma jedynie 2% użytkowników, a jej skuteczne wykorzystanie wymaga zaistnienia serii sprzyjających okoliczności?

Przy podejmowaniu decyzji o podejmowanych akcjach związanych z wykrytą podatnością, warto więc również uwzględnić:

• czy atak działa powtarzalnie (atak, a nie konkretny exploit),
• czy podatność jest łatwa do wykrycia,
• co trzeba mieć/umieć by wykorzystać podatność,
• jakich użytkowników/jak dużej grupy użytkowników dotyczy problem,

Posiadając taką wiedzę można wykonywać sensowne akcje, czyli w pierwszej kolejności eliminować te podatności, dla których ryzyko związane z ich istnieniem jest największe. Właściwie nie tyle istnieniem co wykorzystaniem istniejących podatności, ale skoro podatność została wykryta przez nas, to mogą wykryć ją również ONI, a skoro ją wykryją, to mogą ją zacząć wykorzystywać. Lepiej jednak, by podatność usunąć zanim zostanie wykryta i wykorzystana, ewentualnie można zaakceptować istniejące ryzyko lub próbować je przenieść.