Close

Nasze podejście do zewnętrznych testów zabezpieczeń


Firma Atlassian regularnie otrzymuje prośby o udostępnienie raportów z testów penetracyjnych od klientów, którzy poszukują potwierdzenia skuteczności wdrożonych przez nas procesów mających na celu wykrywanie (i usuwanie) luk w zabezpieczeniach produktów i chmury Atlassian. Nasze podejście do zewnętrznych testów zabezpieczeń opiera się na koncepcji „ciągłego zapewniania bezpieczeństwa”, a nie chwilowych testach penetracyjnych. Wdrożyliśmy model ciągłego zapewniania dostępności i testowania z wykorzystaniem crowdsourcingowego programu wykrywania błędów.

Nasza filozofia i podejście

Jesteśmy dobrze znani z naszych wartości, a wartości te faktycznie wpływają na nasze działania — w tym także na nasze podejście do testów zabezpieczeń. W praktyce nasze wartości doprowadziły nas do wypracowania następujących filozofii i podejść:

  • Błędy są nieuniknioną częścią procesu programistycznego — nie chodzi więc o to, czy istnieją błędy, ale na ile skutecznie i szybko wykrywamy je i eliminujemy. Nie oznacza to, że lubimy błędy lub nie pracujemy stale na innowacyjnymi sposobami zmniejszania częstotliwości ich występowania oraz istotności. Jeśli chodzi o błędy w oprogramowaniu, wyparcie nie jest skutecznym podejściem.
  • Naszym celem jest zwiększenie kosztu znajdowania i wykorzystywania luk w zabezpieczeniach naszych produktów i usług — poprzez szybką identyfikację i rozwiązywanie problemów chcemy zwiększyć koszt ekonomiczny wyszukiwania błędów w zabezpieczeniach. Zwiększenie kosztu wykorzystania luki w zabezpieczeniach — poprzez zwiększenie czasochłonności oraz konieczność posiadania rozleglejszej wiedzy i większej liczby zasobów przez autorów ataków — spowoduje ograniczenie ich zwrotu z inwestycji. Jeśli będziemy w stanie zredukować go w wystarczającym stopniu, zadziała to jako czynnik zniechęcający takie osoby.
  • Wspieramy i wykorzystujemy normy branżowe — standaryzacja naszej terminologii oraz metod ułatwia nam uwzględnienie wszystkich ważnych aspektów i pomaga naszym klientom zrozumieć podejście, jakie stosujemy w naszej pracy. Przykładowo wdrożenie wspólnego sposobu oceniania luk w zabezpieczeniach przy użyciu systemu Common Vulnerability Scoring System (CVSS) pozwala przejrzyście kategoryzować istotność konkretnych luk w komunikacji między nami a naszymi klientami. Stosujemy również procesy zarządzania lukami w zabezpieczeniach opisane w normie ISO 27001 i wytycznych organizacji Cloud Security Alliance (CSA).
  • Zewnętrzni badacze zabezpieczeń stanowią cenne uzupełnienie naszego zespołu — jeśli w zabezpieczeniach produktu Atlassian występuje luka, jej jak najszybsze wykrycie i usunięcie leży w interesie każdego — naszym i naszych klientów. Atlassian motywuje zewnętrznych badaczy do identyfikowania luk w naszych produktach, oferując nagrody pieniężne w ramach naszego programu bug bounty. Dzięki nim możemy skalować nasz zespół w znacznie większym stopniu niż jest to możliwe w przypadku tradycyjnego podejścia.
  • W kwestii naszego programu testowania zabezpieczeń stawiamy na otwartość i przejrzystość — przekazujemy dane statystyczne na temat błędów wykrytych w ramach naszego programu wykrywania błędów, otwarcie informujemy o przewidywanym tempie usuwania błędów w zabezpieczeniach, a w miarę możliwości udostępniamy raporty podsumowujące z testów.

Zapewnianie bezpieczeństwa na bieżąco

Testy penetracyjne

Korzystamy z usług specjalistycznych firm konsultingowych zajmujących się tematyką zabezpieczeń, które poddają produkty i infrastrukturę wysokiego ryzyka testom penetracyjnym. Może to być przeznaczona dla nas nowa konfiguracja infrastruktury (np. nasze środowisko Cloud), nowy produkt (np. Trello) lub fundamentalna zmiana w zakresie architektury (np. szerokie wykorzystanie mikrousług).

Nasze podejście do testów penetracyjnych w tych przypadkach jest wysoce ukierunkowane i skoncentrowane. Zazwyczaj przeprowadzamy następujące testy:

  • Testy strukturalne — testerzy otrzymają dokumentację projektową i omówienia od inżynierów ds. produktów, które ułatwią im przeprowadzenie testów.
  • Testy z wykorzystaniem kodu — testerzy otrzymają pełny dostęp do odpowiedniej bazy kodu, aby ułatwić im zdiagnozowanie wszelkich nieoczekiwanych zachowań systemu w trakcie przeprowadzenia testu i wykrycie potencjalnych celów.
  • Testy oparte na zagrożeniach — takie testy będą koncentrować się na określonym scenariuszu zagrożenia, na przykład przyjęciu, że doszło do naruszenia zabezpieczeń instancji. Dalsza część testu zostanie poprowadzona na zasadzie odgałęzień od przyjętego punktu wyjścia.

U dołu tej strony udostępniamy na użytek zewnętrzny pisma potwierdzające przeprowadzenie oceny (LoA) wystawione przez naszych partnerów odpowiedzialnych za przeprowadzanie testów penetracyjnych. Z uwagi na fakt, że na potrzeby tych ocen przekazujemy testerom obszerne informacje wewnętrzne, nie udostępniamy pełnej treści raportów. Większość tych systemów i produktów zostanie następnie uwzględniona w naszym publicznym programie wykrywania błędów, aby zapewnić ciągłość zewnętrznej kontroli, na której zależy naszym klientom. Wszelkie ustalenia wynikające z tych ocen będą klasyfikowane i obejmowane odpowiednimi działaniami zaradczymi zgodnie z naszą umową SLA dotyczącą publicznych luk w zabezpieczeniach.

Wykrywanie błędów

Nasz program wykrywania błędów jest obsługiwany przez Bugcrowd. Celem tego programu jest zapewnienie, że nasze produkty są stale testowane pod kątem luk w zabezpieczeniach. Jest to centralny element naszego programu zewnętrznych testów zabezpieczeń, będący wynikiem intensywnych badań, analiz i porównywania różnych modeli testowania.

Jesteśmy przekonani, że grono niezależnych badaczy zabezpieczeń biorących udział w naszym programie wykrywania błędów zapewni najskuteczniejszy proces testowania zabezpieczeń, ponieważ:

  1. Program wykrywania błędów działa cały czas. Testy penetracyjne są zasadniczo ograniczone w czasie do kilku tygodni. W środowisku programistycznym działającym faktycznie w oparciu o metodykę Agile, w którym nowe wydania pojawiają się często, nieustanne testowanie jest koniecznością.
  2. Program wykrywania błędów zrzesza ponad 60 000 potencjalnych testerów. Testy penetracyjne są standardowo przeprowadzane przez 1 lub 2 osoby. Bez względu na to, jak wysokie byłyby umiejętności tej 1 lub 2 osób, nie mogą one równać się z połączonymi możliwościami zespołu uczestników programu wykrywania błędów.
  3. Osoby uczestniczące w programie wykrywania błędów opracowują specjalistyczne narzędzia i procesy zarówno w pionie (konkretne typy błędów), jak i w poziomie (konkretne nagrody). Taka specjalizacja znacznie zwiększa szansę wykrycia ukrytych, ale istotnych luk w zabezpieczeniach.

Oprócz tego, w dalszym ciągu korzystamy z testów penetracyjnych i pomocy konsultantów specjalizujących się w zabezpieczeniach w ramach wewnętrznego wsparcia, jednak w przypadku programu zewnętrznego o szerokim zasięgu lepiej sprawdza się program wykrywania błędów. Jesteśmy przekonani, że taka kombinacja podejść maksymalizuje nasze szanse znajdowania luk w zabezpieczeniach.

Nasz program wykrywania błędów obejmuje ponad 25 spośród naszych produktów i środowisk — od produktów serwerowych, poprzez aplikacje mobilne, aż po produkty Cloud. Szczegółowe informacje na temat liczby zgłoszonych luk w zabezpieczeniach, naszego średniego czasu reakcji i średniego wynagrodzenia można znaleźć w witrynie Bugcrowd. W naszym programie zarejestrowało się już ponad 800 testerów.

Luki w zabezpieczeniach, które staramy się wykryć w ramach naszego programu wykrywania błędów, obejmują często występujące rodzaje zagrożeń odnotowane na listach Open Web Application Security Project (OWASP) i Web Application Security Consortium (WASC). Można wśród nich wymienić:

  • Wyciek danych lub dostęp do danych między różnymi instancjami
  • Zdalne wykonanie kodu (RCE)
  • Server-Side Request Forgery (SSRF)
  • Cross-site Scripting (XSS)
  • Cross-site Request Forgery (CSRF)
  • SQL Injection (SQLi)
  • Ataki XML External Entity (XXE)
  • Luki w zabezpieczeniach kontroli dostępu (Insecure Direct Object Reference itp.)
  • Luki typu Path/Directory Traversal

W ramach naszej inicjatywy zapewniania otwartości i przejrzystości zapraszamy wszystkich do odwiedzenia strony naszego programu wykrywania błędów, zarejestrowania się w programie i przetestowania naszych produktów.

Aplikacje ze sklepu Marketplaceaplikacje ze sklepu Marketplace są wyłączone z głównego programu wykrywania błędów Atlassian. Jednak aplikacje za sklepu Marketplace są objęte osobnymi programami wykrywania błędów prowadzonymi przez Atlassian, takimi jak program ujawniania luk w zabezpieczeniach i program wykrywania błędów w aplikacjach opracowanych przez Atlassian.

Testy inicjowane przez klientów — zgodnie z naszymi Warunkami użytkowania produktów Cloud zezwalamy na przeprowadzanie testów inicjowanych przez klientów. Chcemy działać otwarcie i będziemy nadal regularnie publikować statystyki z naszego programu wykrywania błędów.

Choć jesteśmy przekonani, że nasz program wykrywania błędów jest bardziej wydajnym i ekonomicznym sposobem oceny bezpieczeństwa naszych produktów, zdajemy sobie sprawę, że nasi klienci mogą wyrażać chęć samodzielnego przetestowania zabezpieczeń. Zezwalamy klientom na przeprowadzanie ocen zabezpieczeń (testów penetracyjnych, ocen luk w zabezpieczeniach), prosimy jednak o przestrzeganie kilku zasad, które pomogą zapewnić bezpieczeństwo nam wszystkim. Jeśli udało Ci się znaleźć błąd i chcesz go zgłosić, w naszej witrynie znajdziesz również instrukcje zgłaszania luk w zabezpieczeniach.

Zgłaszanie luk w zabezpieczeniach

Jeśli w trakcie standardowego korzystania z naszego produktu jeden z naszych użytkowników wykryje lukę w zabezpieczeniach (mowa o lukach wykrytych poza konkretnymi próbami testowania systemu, które muszą odbywać się w ramach naszego programu wykrywania błędów), zachęcamy do powiadomienia nas o tym za pośrednictwem zespołu wsparcia Atlassian. Niezwłocznie reagujemy na wszelkie przekazane informacje o lukach w zabezpieczeniach i na bieżąco informujemy zainteresowane strony o postępach w dochodzeniu i reakcji na problem.

Prosimy badaczy, aby przed publicznym ujawnieniem problemu, najpierw zwrócili się do nas o zgodę. Atlassian będzie rozpatrywać wnioski o publiczne ujawnienie indywidualnie dla każdego zgłoszenia. Wnioski o publiczne ujawnienie będą uwzględniane dopiero po wyeliminowaniu zgłoszonej luki w zabezpieczeniach.

Wykluczenia z naszego programu testowania zabezpieczeń

Z równą otwartością i przejrzystością, jak do przeprowadzanych przez nas testów, podchodzimy również do testów, których nie przeprowadzamy samodzielnie ani obecnie nie obsługujemy. Nasz program testowania zabezpieczeń nie obejmuje następujących elementów:

Określone rodzaje luk w zabezpieczeniach o niskim poziomie ryzyka — nasze produkty zostały opracowane z myślą o uwolnieniu potencjału tkwiącego w każdym zespole, a to wymaga współpracy. Luki związane z wyliczeniami i zbieraniem informacji zasadniczo nie są uznawane za istotne obszary ryzyka.

Pomiar właściwych elementów

Mamy zasady usuwania błędów, które funkcjonują jak wewnętrzna umowa o gwarantowanym poziomie świadczenia usług (SLA) między naszymi zespołami ds. produktów a zespołem ds. bezpieczeństwa. Do kategoryzowania błędów używamy systemu Common Vulnerability Scoring System (CVSS wer. 3), który ułatwia informowanie naszych klientów o tym, jak istotne są poszczególne luki w zabezpieczeniach. Staramy się przestrzegać następujących ram czasowych usuwania problemów z zabezpieczeniami:

  • Błędy krytyczne (wynik >= 8 wg CVSS wer. 2, wynik >= 9 wg CVSS wer. 3) powinny być usuwane z produktu w ciągu 4 tygodni od zgłoszenia.
  • Błędy bardzo istotne (wynik >= 6 wg CVSS wer. 2, wynik >= 7 wg CVSS wer. 3) powinny być usuwane z produktu w ciągu 6 tygodni od zgłoszenia.
  • Błędy średnio istotne (wynik >= 3 wg CVSS wer. 2, wynik >= 4 wg CVSS wer. 3) powinny być usuwane z produktu w ciągu 8 tygodni od zgłoszenia.

Te ramy czasowe co roku poddaje się ewaluacji, a w razie potrzeby dostosowuje do zmieniającego się środowiska zagrożeń.

Ponadto biorąc pod uwagę, że naszym celem jest zwiększenie kosztu znajdowania i wykorzystywania luk w zabezpieczeniach naszych produktów, potrzebny jest sposób określania takiego kosztu. W ramach zachęty oferujemy badaczom zabezpieczeń „nagrodę” za wykrycie luki w zabezpieczeniach. Mówiąc najprościej, z czasem liczba błędów wykrywanych za pośrednictwem naszego programu wykrywania błędów powinna się zmniejszać, a wówczas będziemy musieli zwiększyć kwotę oferowaną za wykrycie takich błędów, jeśli chcemy, aby nadal napływały do nas zgłoszenia. Jeśli nakład pracy potrzebny do znalezienia luki w zabezpieczeniach przy nagrodzie wynoszącej 3000 USD sprawi, że nie będzie się to opłacać (ponieważ wymaga to nakładu pracy wartego więcej niż 3000 USD), zwiększymy koszt wyszukania takiej luki.

Innymi słowy należy się spodziewać, że z czasem kwoty nagród będą wzrastać.

Podsumowanie

Atlassian dysponuje dojrzałym, otwartym i przejrzystym programem zewnętrznych testów zabezpieczeń, którego główny element stanowi program wykrywania błędów.

Chcesz pogłębić swoją wiedzę?

W tym krótkim artykule odnieśliśmy się do kilku innych dokumentów i zasobów. Zachęcamy, aby do nich sięgnąć. Pozwoli to lepiej zrozumieć nasze podejście do testowania zabezpieczeń.

Pobieranie aktualnych raportów z programu wykrywania błędów

Wszelkie luki w zabezpieczeniach wskazane w poniższych raportach są śledzone w naszym wewnętrznym systemie Jira od momentu ich zgłoszenia w ramach programu wykrywania błędów, a wszelkie ustalenia wynikające z programu wykrywania błędów będą klasyfikowane i obejmowane odpowiednimi działaniami zaradczymi zgodnie z naszą umową SLA dotyczącą publicznych luk w zabezpieczeniach.

Pobieranie pism potwierdzających przeprowadzenie oceny (LoA)

Wszelkie luki w zabezpieczeniach wskazane w poniższych raportach są śledzone w naszym wewnętrznym systemie Jira od chwili ich zgłoszenia za pośrednictwem procesu raportowania wyników testów penetracyjnych, a wszelkie ustalenia wynikające z tych ocen będą klasyfikowane i obejmowane odpowiednimi działaniami zaradczymi zgodnie z naszą umową SLA dotyczącą publicznych luk w zabezpieczeniach.