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 na dole tej strony.
  

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 naszym docelowym poziomem świadczenia usług (SLO) dotyczącym 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 Marketplace — aplikacje ze sklepu Marketplace są wyłączone z głównego programu wykrywania błędów Atlassian. Są one jednak 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 stanowi bardziej wydajny i ekonomiczny sposób 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.

Zgłaszanie luk w zabezpieczeniach

Jeśli udało Ci się znaleźć błąd i chcesz go zgłosić Atlassian, zapoznaj się z instrukcjami zgłaszania luk w zabezpieczeniach.

Jedna z głównych dewiz Atlassian to „Otwarta firma, bez nonsensów” i wierzymy, że ujawnianie luk w zabezpieczeniach jest jej integralną częścią. Staramy się usuwać luki w zabezpieczeniach zgodnie z odpowiednimi docelowymi poziomami świadczenia usług (SLO). Przyjmujemy wnioski o ujawnienie luk złożone za pośrednictwem naszych programów wykrywania błędów po usunięciu problemu i uwzględnieniu poprawki w wydaniu produkcyjnym. Jeśli jednak raport zawiera jakiekolwiek dane klienta, wniosek zostanie odrzucony. Jeśli planujesz ujawnić luki poza naszymi programami wykrywania błędów, powiadom nas o tym odpowiednio wcześniej i poczekaj, aż minie termin określony w powiązanym docelowym poziomie świadczenia usług (SLO).

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

Nasze zasady usuwania błędów zabezpieczeń określają ramy czasowe docelowego poziomu świadczenia usług (SLO) dotyczące eliminowania luk w zabezpieczeniach na podstawie ich ważności i produktu. Do oceny luk w zabezpieczeniach używamy systemu Common Vulnerability Scoring System, który ułatwia informowanie naszych klientów o tym, jak istotne są poszczególne luki.

Ponadto naszym celem jest zwiększenie kosztu znajdowania i wykorzystywania luk w zabezpieczeniach naszych produktów. Do obliczania tego kosztu wykorzystujemy programy wykrywania błędów. W miarę jak nasze zabezpieczenia będą udoskonalane liczba błędów wykrywanych za pośrednictwem naszych programów 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 wartościowe zgłoszenia. Przykładowo, 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ń.

• Centrum zaufania Atlassian
• Praktyki Atlassian w zakresie bezpieczeństwa
• Wpis w rejestrze CSA STAR dotyczący Atlassian
• Zasady usuwania błędów Atlassian
• Strona zgłaszania luk w zabezpieczeniach Atlassian
• Obowiązki Atlassian dotyczące incydentów związanych z bezpieczeństwem
• Strona główna programu wykrywania błędów Atlassian
• Programy wykrywania błędów Atlassian
  • Wykrywanie błędów w aplikacjach ze sklepu Marketplace opracowanych przez Atlassian
  • Wykrywanie błędów w aplikacjach ze sklepu Marketplace opracowanych przez dostawców zewnętrznych
  • Wykrywanie błędów w Opsgenie
  • Wykrywanie błędów w Statuspage
  • Wykrywanie błędów w Trello
  • Wykrywanie błędów w Halp
  • Wykrywanie błędów we wszystkich innych produktach Atlassian (Jira, Confluence, Bitbucket itp.)

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 naszym docelowym poziomem świadczenia usług (SLO) dotyczącym publicznych luk w zabezpieczeniach.

• Pobierz najnowszy raport z programu wykrywania błędów Atlassian (styczeń 2023)
• Pobierz najnowszy raport z programu wykrywania błędów Halp (styczeń 2023)
• Pobierz najnowszy raport z programu wykrywania błędów Jira Align (styczeń 2023)
• Pobierz najnowszy raport z programu wykrywania błędów Opsgenie (styczeń 2023)
• Pobierz najnowszy raport z programu wykrywania błędów Statuspage (styczeń 2023)
• Pobierz najnowszy raport z programu wykrywania błędów Trello (styczeń 2023)

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 naszym docelowym poziomem świadczenia usług (SLO) dotyczącym publicznych luk w zabezpieczeniach.

• Pismo potwierdzające przeprowadzenie oceny — Jira Align (kwiecień 2022)
• Pismo potwierdzające przeprowadzenie oceny — Bitbucket Pipelines (maj 2022)
• Pismo potwierdzające przeprowadzenie oceny — Trello (sierpień 2022)
• Pismo potwierdzające przeprowadzenie oceny — Bitbucket Server i DC (wrzesień 2022)
• Pismo potwierdzające przeprowadzenie oceny — Confluence Cloud (październik 2022)
• Pismo potwierdzające przeprowadzenie oceny — Jira Service Management Data Center (październik 2022)
• Pismo potwierdzające przeprowadzenie oceny — Jira Cloud Google OAuth (październik 2022)
• List oceniający dla Atlassian Log4j Library for Confluence and Jira (2022-12)
• Pismo potwierdzające przeprowadzenie oceny — Confluence Server (grudzień 2022)
• Pismo potwierdzające przeprowadzenie oceny — Jira Work Management Cloud (grudzień 2022)
• Pismo potwierdzające przeprowadzenie oceny — Bitbucket Cloud (grudzień 2022)
• Pismo potwierdzające przeprowadzenie oceny — Statuspage Cloud (grudzień 2022)
• Pismo potwierdzające przeprowadzenie oceny — Jira Software (Cloud) (luty 2023)
• Pismo potwierdzające przeprowadzenie oceny — Bamboo (luty 2023)