Bezpieczeństwo kontra zgodność

Autor: Wes Miller

Opublikowano: 25 września 2008

Zawartość strony

	Bezpieczeństwa nie należy odfajkowywać
	Całościowy obraz
	Wystarczająco dobre
	Zadecydujmy, gdzie jesteśmy
	Co mamy do stracenia?
	W pogoni za własnym ogonem
	Przyjmijmy wyzwanie
	Materiały dotyczące cyklu SDL
	Materiały dotyczące bezpieczeństwa i zgodności

Profesjonaliści IT muszą niekiedy stawiać czoła celom, które powinny się uzupełniać, a zamiast tego konkurują ze sobą. Bezpieczeństwo i zgodność z regulacjami to dwa tego typu wymagania organizacji, gdzie spełnienie jednego powinno sprzyjać spełnieniu drugiego. Niestety czasem bywa inaczej. Niniejszy artykuł ma na celu zaprezentowanie, dlaczego zapewnienie bezpieczeństwa nie zawsze gwarantuje zachowanie zgodności z pewnymi narzuconymi odgórnie inicjatywami oraz dlaczego zgodność często wcale nie oznacza bezpieczeństwa lub przynajmniej nie w stopniu, który wskazywałby, że zgodność z regulacjami naprawdę ma służyć zapewnieniu bezpieczeństwa.

Bezpieczeństwa nie należy odfajkowywać

Zgodność (ang. compliance) zazwyczaj wiąże się z wymaganiami (dotyczącymi ludzi, procesów infrastruktury, technologii itd.) odgórnie narzuconymi organizacji, firmie lub produktowi. Niekiedy zgodność ma związek ze standardami spopularyzowanymi w danej branży (takimi jak standard Payment Card Industry Data Security Standards, w skrócie PCI-DSS). Idealnie byłoby, gdyby inicjatywy te były zgodne z dotychczasowym sposobem działania organizacji, przynajmniej w pewnym stopniu. Standardy stają się coraz powszechne, nie można pozwolić sobie na ich ignorowanie, w świecie biznesu i tak trzeba będzie w końcu kiedyś się dostosować i zrobić z nich jak najlepszy użytek.

Istnieje także inny typ zgodności, który jest zwykle bardziej problematyczny. Chodzi o inicjatywy przedkładane przez rząd, takie jak ustawy Health Insurance Portability and Accountability (HIPAA) oraz Sarbanes-Oxley, których implementacja i planowanie jest rzadko kwestią wyboru.

Kluczową kwestią, którą należy zrozumieć w kontekście zgodności z wymogami prawnymi, jest to, że często przyjmują one podejście odgórne. Istnieje zazwyczaj masowy szablon, który definiuje inicjatywę, a my musimy przeanalizować nasze produkty i procesy, zastanawiając się, w jaki sposób mogą one zazębić się z dziwnie ukształtowanym szablonem, jaki został nam przekazany. Trzeba zdawać sobie sprawę nie tylko z intencji inicjatyw dotyczących zgodności z przepisami, ale również co ważniejsze z konsekwencji prawnych lub finansowych, jakie grożą nam w przypadku niezastosowania się do nich lub nieskutecznego ich stosowania (jeśli takowe reperkusje istnieją).

Choć możemy zgodzić się z intencją wielu tego typu inicjatyw, ich zaimplementowanie bywa często trudne i może nie być zgodne z oczekiwanym celem. Niestety wiele ustaw jest bezzębnych (to znaczy, że ich nieprzestrzeganie nie wiąże się z żadnymi bezpośrednimi reperkusjami ani prawnymi, ani finansowymi).

Jako pacjent mogę przedstawić bezpośrednie korzyści płynące z wprowadzenia standardu HIPAA. Oznacza ono, że podczas każdej wizyty u lekarza czeka mnie więcej papierkowej roboty. Co gorsza mogą istnieć także niezamierzone konsekwencje. Czy któryś z czytelników próbował kiedyś wydostać ważne dane medyczne od jednego lekarza i przenieść je do drugiego? Bez pisemnej zgody się nie obędzie, nieważne jak pilnie potrzebna jest wybrana informacja.

Efekt jest taki, że pewne inicjatywy dotyczące zgodności z przepisami stanowią pod wieloma względami wymogi "do odfajkowania". To znaczy, że projektujemy lub modyfikujemy proces lub produkt jedynie po to, aby zapewnić zgodność z daną regulacją. Nasuwa się pytanie, które autor często zadaje swojemu trzylatkowi, "czy to jest dobry pomysł"?

Natomiast bezpieczeństwo to inicjatywa o charakterze od szczegółu do ogółu (o ile jest w odpowiedni sposób realizowana). Gdy projektujemy produkt programistyczny lub architekturę nowej sieci w organizacji, powinniśmy pamiętać o kluczowej zasadzie: "mierz dwa razy, tnij raz". Gdy planujemy na przykład architekturę produktu, prawidłowo przeprowadzona wstępna faza projektu powinna wiązać się z opisaniem nie tylko komunikacji, lokalizacji, wersji itd., ale także elementów zabezpieczeń, które muszą zostać od początku wbudowane w aplikację (i które powinny być analizowane i redefiniowane w fazie rozwoju).

Gdy pracujemy z istniejącą aplikacją lub architekturą (co zapewne dotyczy większości czytelników), również ważne jest zrealizowanie szczegółowej analizy zabezpieczeń, o której autor często wspomina w swoich artykułach. Jeśli nie rozumiemy, w jaki sposób coś działa, jak możemy ocenić poziom bezpieczeństwa? Więcej informacji na temat cyklu Microsoft® Security Development Lifecycle (SDL) znaleźć można w sekcji "Materiały dotyczące cyklu SDL".

 Do początku strony

Całościowy obraz

Kiedyś uczono, iż bezpieczeństwo to nie tylko proste zaimplementowanie szyfrowania, list kontroli dostępu (ACL) lub TLS bądź infrastruktury klucza publicznego (PKI). Prawdziwe bezpieczeństwo polega na zrozumieniu całościowego obrazu, zrozumieniu: dlaczego ta wersja tamtego protokołu została zaniechana lub nigdy nie była wspierana, dlaczego nowy element infrastruktury zatrzymuje ataki typu man-in-the-middle, pod jakimi względami implementacja produktu v2 jest bezpieczniejsza niż v1, nawet jeśli v1 była szybsza. Niezbędna jest także świadomość, w jaki sposób wszystkie poszczególne części infrastruktury współpracują ze sobą.

Natomiast zgodność oznacza przeanalizowanie technologii celu upewnienia się, że zbudowana infrastruktura spełnia określone kryteria. Pewne inicjatywy, takie jak standard Payment Card Industry Data Security Standards (PCI-DSS) lub North American Electric Reliability Council (NERC) są dobrze przemyślane i mogą pociągać za sobą prawdziwe zmiany w zakresie bezpieczeństwa. Jednak szeroki wachlarz "inicjatyw dotyczących zgodności", do których musimy dostosować dany projekt i ograniczona dostępność zasobów powodują, że inicjatywy dotyczące bezpieczeństwa trącą na ważności.

Bezpieczeństwo przez długi czas stanowiło zaniedbywany aspekt rozwoju oprogramowania. Z pewnością wielu czytelników miało okazję pracować w organizacjach, w których bezpieczeństwo było traktowane jako coś, "czym zajmiemy się później". Cóż, inicjatywy dotyczące zgodności stały się codziennością właśnie ze względu na to, że idea "bezpieczeństwo może poczekać" nie sprawdza się i nigdy się nie sprawdzała.

 Do początku strony

Wystarczająco dobre

Autor artykułu niedawno zmienił pracę. Obecnie pracuje dla młodej firmy w Austin w Teksasie, która buduje technologie "białej listy" aplikacji w pewnym stopniu podobną do technologii, jaką budował w firmie Winternals w produkcie Protection Manager. Bardzo interesującym doświadczeniem są rozmowy z klientami o tym, jak oceniają bezpieczeństwo swoich aktualnych technologii, a dokładniej jak bezpieczna ich zdaniem jest ich infrastruktura, dzięki zastosowaniu wybranego zestawu technologii. Chociaż całkowicie prawdopodobne, że większość z nich faktycznie jest bezpieczna i nie posiada wyeksponowanych luk zabezpieczeń, autorowi często zdarza się słyszeć niepokojącą opinię, że system jest "wystarczająco bezpieczny".

Inicjatywy dotyczące zgodności są dość osobliwe, można spełniać ich wymogi lub nie. Odpowiedzialność leży po naszej stronie. Konsekwencją nieprzestrzegania regulacji jest zwykle grzywna, sankcje karne lub wykluczenie z organizacji. Często nie wystarczy zapewnić, że zmiany naprawdę są wprowadzane.

W przypadku inicjatywy nadzorowanych przez państwo autor często napotyka nastawienie "wystarczająco dobry, aby przejść kontrolę". Firmy decydują się czasem na niestosowanie żadnej struktury zgodności, ponieważ wsparcie dla legislacji (takich HIPAA) w praktyce nie obejmuje mechanizmów ich egzekwowania. A to oznacza, że dużo mniej kosztowna jest "jazda bez ubezpieczenia" i sprostanie ewentualnym konsekwencjom w przyszłości.

Bezpieczeństwo często napotyka te same przeszkody, jednak przynajmniej są one bardziej konkretne. Jeśli, jako projektanci lub programiści, poinformujemy zarząd, że pozostawienie sekcji foo poza specyfikacją sprawi, że produkt będzie znacznie bardziej podatny na ataki, po opublikowaniu projektu lub zakończeniu wdrożenia będziemy przynajmniej mogli powiedzieć "A nie mówiłem". Doświadczenie autora związane z inicjatywami dotyczącymi zgodności jest takie, że ich wdrożenie jest często przyspieszane przy możliwie jak najmniejszym budżecie. Celem jest po prostu spełnienie jedynie minimalnych wymagań, co zdaniem autora sprowadza się często do przestrzegania litery prawa, ale nie ducha inicjatywy.

 Do początku strony

Zadecydujmy, gdzie jesteśmy

Chociaż stwierdzenie, iż należy uczynić produkt i organizację tak bezpieczną, jak to tylko możliwe, może wydawać się idealistyczne, rzeczywistość jest taka, iż większość inicjatyw dotyczących zgodności jest narażona na porażkę ze względu na niewystarczające umiejętności inżynierskie lub co się częściej zdarza brak krytycyzmu. Żyjemy w świecie, gdzie "wystarczająco dobre" niestety jest wystarczająco dobre. Jednak w świecie zabezpieczeń "wystarczająco dobrze" rzadko stanowi rozsądną opcję. My, profesjonaliści IT z całego świata, możemy brać sobie inicjatywy dotyczące zgodności do serca i próbować im sprostać zarówno w kontekście idei jak i implementacji, ale nadal musimy upewniać się, że realizowana przez nas infrastruktura nie jest jedynie bezpieczna na tyle, na ile może być bezpieczna, ale na tyle na ile musi być bezpieczna. Innymi słowy musimy zachować zgodność poprzez prawdziwe bezpieczeństwo, a nie tylko poprzez zgodność z narzuconymi regulacjami.

Ważne jest, abyśmy spojrzeli z dystansu na budowaną przez nas technologię, niezależnie o tego czy jest to fragment oprogramowania komercyjnego czy zestaw technologii, które chcemy zintegrować z większym systemem. Nie sposób przecenić wagi zrozumienia zazębiających się elementów systemu, ich wzajemnej współpracy oraz większych zagrożeń, na jakie narażony jest system.

W zależności od branży, w której pracujemy, w grę mogą wchodzić różne inicjatywy dotyczące zgodności. Możemy napotykać je na co dzień lub jedynie podczas opracowywania nowych projektów lub technologii. Mogą one mieć wpływ na naszą pracę jedynie w czasie wykonywania specjalnych, dedykowanych analiz lub inspekcji zgodności. Niezależnie od tego autor tego artykułu nie twierdzi, że należy ignorować inicjatywy dotyczące zgodności. Jednak zachęca do próby podważenia statusu quo. Być może warto nie ograniczać się do wymogów narzuconych przez regulacje, ale w czasie przeprowadzania analizy zgodności jednocześnie zrealizować pełną analizę zabezpieczeń w celu dokładnego zrozumienia technologii i zamodelowania jej.

 Do początku strony

Co mamy do stracenia?

Prawda jest taka, że grzywny za niespełnianie wymogów inicjatyw dotyczących zgodności mogą wydawać się niesprecyzowane. Brak zgodności naraża nas na ryzyko dokładnie takiego scenariusza, przed którym ma chronić dana inicjatywa. Konsekwencje mogą wydawać się niejasne lub odległe, ale są rzeczywiste. Mogą dotknąć nie tylko nas (personalnie). Musimy być pragmatyczni, ale pamiętając jednocześnie o najczarniejszym scenariuszu.

Gdy spojrzymy na ten sam problem ściśle z punktu widzenia bezpieczeństwa, zagrożenie powinno być oczywiste, a co ważniejsze powinniśmy mieć możliwość natychmiastowego zidentyfikowania potencjalnych konsekwencji pozostawienia niezabezpieczonej luki.

Wiele osób, z którymi autor miał okazję dyskutować na ten temat, podkreślało fakt, iż inicjatywy dotyczące zgodności są czasem zamiatane pod dywan, ponieważ często pozostawiają duże pole do interpretacji. Jednak nie powinno być tak w przypadku analizy bezpieczeństwa. Natychmiastowe zagrożenia wynikające ze zignorowania luk zabezpieczeń powinny być wyraźnie widoczne. Jeśli nie są, warto zastanowić się, kto jest zaangażowany w proces analizy bezpieczeństwa. Być może brakuje kluczowych członków zespołu, którzy mogliby pomóc w odnalezieniu rzeczywistych, słabych stron danego rozwiązania.

 Do początku strony

W pogoni za własnym ogonem

W opublikowanym w zeszłym roku artykule "How Not to Lose Your Data" dotyczącym zabezpieczeń autor opisał metody minimalizowania ryzyka utraty danych (technet.microsoft.com/magazine/cc162325). Od tego czasu minął rok, zabezpieczenia większej liczby systemów zostały złamane, więcej niezaszyfrowanych laptopów zostało skradzionych i więcej informacji personalnych znalazło się w niepowołanych rękach. Trudno powiedzieć, czy osiągnięty został jakikolwiek postęp. Dlaczego stoimy w miejscu? Projekty często się opóźniają, mają skąpe budżety i absurdalnie przeciążone zasoby, próbując dostarczyć zbyt wiele funkcji w zbyt krótkim czasie.

Tego typu środowisko prowadzi niestety do sytuacji, w której absolutnie minimalny nakład pracy staje się normą. W ten sposób z pewnością nie można zapewnić zgodności i bezpieczeństwa rozwiązania, nie bez katastrofalnych skutków dla planu i kosztu projektu.

Autor tego artykułu jest osobiście przekonany, że:

  1.  Nie należy budować rozwiązania, gdy nie jest się gotowym na jego zabezpieczenie.

  2.  Za każdym razem, gdy dodaje się nowe funkcje, należy najpierw zaprojektować ich zabezpieczenia.

  3.  Jeśli organizacja nie uwzględnia projektu zabezpieczeń jako kroku w procesie inżynierskim, podważa to ogólne cele firmy i organizacji.

Organizacje coraz częściej dysponują danymi personalnymi klientów lub partnerów i są odpowiedzialne za ich ochronę. Niestety żyjemy w świecie, w którym zbyt często bezpieczeństwo nie jest domyślnym priorytetem i pracownicy nie czują się bezpieczni, nie mając pewności, czy ich organizacja troszczy się o zabezpieczenia.

Rzeczywiste braki zabezpieczeń (nie braki zgodności) zbyt często stanowią krytyczny argument przemawiający za spóźnionym zabezpieczaniem systemu. "Ubezpieczenie od kradzieży tożsamości" stało się standardowym sposobem unikania odpowiedzialności, który ma na celu ugłaskanie klientów, studentów, pacjentów i pracowników, których dane personalne i potencjalne powodzenie finansowe zostało narażone na szwank.

Często jesteśmy proszeni o to, żeby zrobić zbyt wiele za zbyt niewiele i zazwyczaj w zbyt krótkim czasie. Jednak to po naszej stronie jako profesjonalistów IT leży zadawanie pytań, dlaczego bezpieczeństwo nie stanowi kluczowego priorytetu, dlaczego zbyt często zarząd postrzega bezpieczeństwo jedynie w kategorii inicjatyw dotyczących zgodności bądź realnych lub potencjalnych konsekwencji prawnych awarii zabezpieczeń (które mogłyby potencjalnie postawić organizację w kłopotliwej sytuacji lub nawet narazić na ryzyko).

 Do początku strony

Przyjmijmy wyzwanie

Z całego serca zachęcam do podważenia istniejącego stanu rzeczy. Gdy ktoś prosi nas o spełnienie wymogów zgodności, spróbujmy ustalić, czy nie marnujemy jedynie naszego czasu, realizując cudzą koncepcję bezpieczeństwa. Upewnijmy się, czy celem jest zabezpieczenie systemu i jednoczesne zdefiniowanie procesów lub infrastruktury, która wystarczy do spełnienia wymogów inicjatywy dotyczącej zgodności. W poszukiwaniu dodatkowych informacji na ten temat pomóc może sekcja "Materiały dotyczące bezpieczeństwa i zgodności".

Podsumowując, pamiętajmy, że zgodność zbyt często wcale nie prowadzi do bezpieczeństwa. Jednak bezpieczeństwo, gdy jest odpowiednio zaimplementowane i monitorowane, pozwala często osiągnąć zgodność z przepisami.

 Do początku strony

Materiały dotyczące cyklu SDL

  •   The Security Development Lifecycle, autorzy: Michael Howard i Steve Lipner (Microsoft Press, 2006)

  •   The Security Development Lifecycle Blog

  •  A Look inside the Security Development Lifecycle at Microsoft

  •  Security Developer Center

  •  The Trustworthy Computing Security Development Lifecycle

 Do początku strony

Materiały dotyczące bezpieczeństwa i zgodności

  •  Security and Compliance Solutions Guidance

  •  Security Guidance

  •  Payment Card Industry Data Security Standard Compliance Planning Guide

  •  Regulatory Compliance and Security Updates

  •  Achieving Compliance

  •  Office for Civil Rights—HIPAA

  •  PCI Security Standards Council

  •  North American Electric Reliability Council

O autorze

Wes Miller piastuje stanowisko Senior Technical Product Manager w firmie CoreTrace (www.CoreTrace.com) w Austin w Teksasie. Dawniej pracował w firmie Winternals Software oraz jako Program Manager w firmie Microsoft. Można skontaktować się z nim przy pomocy adresu technet@getwired.com.

Do początku strony