Chmury w szoku muszlowym?

We wrześniu 2014 roku kolejna bomba, „Shellshock”, uderzyła w społeczność zajmującą się bezpieczeństwem w postaci zestawu luk w „Bash”, składniku większości systemów opartych na systemie UNIX. Może wyrządzić ogromne szkody, a społeczność gorączkowo próbuje naprawić każdy system, którego dotyczy problem. Dokonano już milionów prób ataków na prawie każdy system w Internecie, a niektórzy napastnicy próbowali przekształcić go w samoreplikującego się „robaka”. Aby sieci dostawców mogły zostać uznane za bezpieczne, muszą być chronione wielowarstwowymi zaporami ogniowymi i systemami wykrywania włamań. Sieci te muszą być również monitorowane przez Security Operations Center (SOC) w trybie 24x7x365. Jedynym trwałym podejściem do bezpieczeństwa jest strategia „BEZPIECZEŃSTWO W GŁĘBOKOŚCI”, podobna do tej stosowanej w LiveOps, z wieloma nakładającymi się i nadmiarowymi warstwami ochrony.

W LiveOps stosujemy holistyczne podejście do bezpieczeństwa. Nasz zespół ds. bezpieczeństwa aplikacji analizuje każdy krok od momentu, w którym projekt jest przewidywany i umieszczany na desce kreślarskiej, przez etapy jego opracowywania i testowania, aż do wdrożenia. Bezpieczeństwo musi być integralną częścią sposobu, w jaki dostawca projektuje i buduje swoją platformę na każdym etapie cyklu życia oprogramowania – a nie refleksją. Co więcej, system bezpieczeństwa powinien zostać dokładnie przetestowany, aby udowodnić, że rozwiązanie spełnia lub przewyższa branżowe wymagania bezpieczeństwa. Systemy oparte na chmurze wymagają całodobowego monitorowania w celu zapewnienia bezpieczeństwa i integralności danych klientów, ochrony przed zagrożeniami bezpieczeństwa lub naruszeniami danych oraz zapobiegania nieautoryzowanemu dostępowi do danych klientów.

Natychmiast po umieszczeniu systemu w naszych bezpiecznych centrach danych jest on monitorowany i audytowany, aktualizowany i analizowany. Dane są chronione do samego końca, kiedy wiele lat później dysk twardy, na którym znajdują się dane, znajdzie swoje miejsce ostatecznego spoczynku w niszczarce przemysłowej w centrum recyklingu.

Za każdym razem, gdy zostanie ujawniona luka, jak w przypadku Shellshock (lub dowolnej z dziesiątek mniej widocznych luk, które są wykrywane co miesiąc), zespół LiveOps analizuje wpływ, decyduje o planie naprawczym i wdraża go wraz z odpowiednim zespołem.

W przypadku Shellshock nasze podejście składało się z siedmiu następujących kroków:

  1. Wyszukuj wszelkie przypadki publicznych luk w zabezpieczeniach, korzystając z automatycznych skanów pochodzących od wielu dostawców i testów ręcznych. (Nie znaleziono żadnego).
  2. Zaktualizuj reguły zapory aplikacji sieci Web i powiadom zespół Security Operation Center.
  3. Przejrzyj dzienniki IDS pod kątem prób ataku. (Różne próby były widoczne, ale żadna nie zakończyła się sukcesem).
  4. Wdrożenie na pełną skalę odpowiednich poprawek z różnymi iteracjami.
  5. Przetestuj kod weryfikacji koncepcji, aby zweryfikować powodzenie łatania na każdej maszynie.
  6. Przeprowadź wewnętrzne skanowanie pod kątem luk w zabezpieczeniach, aby sprawdzić, czy żadne pola nie zostały pominięte.
  7. Przeprowadź przegląd „białej skrzynki” całego kodu źródłowego produkcji pod kątem użycia „bash”.

Niektóre z tych zadań były wykonywane równolegle i wymagały wysiłku całego zespołu, ale udało nam się szybko rozwiązać ten problem, bez narażania bezpieczeństwa i bez wpływu na procesy produkcyjne.

Co możesz zrobić jako użytkownik systemów chmurowych?

Oprócz zwykłych najlepszych praktyk w zakresie bezpieczeństwa (w sprawie których zawsze chętnie doradzamy naszym klientom), jedyne, co należy zrobić, to zachować czujność i upewnić się, że odpowiednio sprawdziłeś swojego dostawcę usług w chmurze.

Takie incydenty będą się powtarzać w przyszłości. Pamiętaj, aby wybrać partnera, który jest na nie gotowy.

Zdjęcie dzięki uprzejmości Stuarta Milesa z FreeDigitalPhotos.net.