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

Atlassian stosuje wieloaspektowe podejście do zapewnienia bezpieczeństwa naszych produktów z wykorzystaniem metod zewnętrznych. Nieustannie prowadzimy program wykrywania błędów oparty na crowdsuourcingu, którego dopełnieniem są regularne strukturalne testy penetracyjne przeprowadzane przez zewnętrzne firmy konsultingowe zajmujące się bezpieczeństwem i nasz wewnętrzny zespół ds. testowania zabezpieczeń.

Nasza filozofia i podejście

Jesteśmy znani z wartości, które faktycznie wpływają na nasze działania — w tym na podejście do testowania 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 w naszych produktach są błędy, ale na ile skutecznie i szybko wykrywamy je i eliminujemy. Nie oznacza to, że lubimy błędy ani że nie wprowadzamy cały czas innowacyjnych sposobów zmniejszania ich częstotliwości i ważności. Jeśli chodzi o błędy w oprogramowaniu, wyparcie nie jest skutecznym podejściem.
• Przestrzegamy norm branżowych i stosujemy je w praktyce — standaryzacja naszej terminologii oraz metod ułatwia nam uwzględnienie wszystkich ważnych aspektów i pomaga naszym klientom zrozumieć, co i dlaczego robimy. Przykładowo wdrożenie standardowego sposobu oceniania luk w zabezpieczeniach przy użyciu systemu Common Vulnerability Scoring System (CVSS) pozwala przejrzyście kategoryzować ważność 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 testerzy zabezpieczeń i testerzy penetracyjni 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 angażuje niezależnych zewnętrznych testerów penetracyjnych, którzy co roku sprawdzają nasze produkty pod kątem luk w zabezpieczeniach i uzupełniają działania naszego wewnętrznego zespołu ds. bezpieczeństwa, wykonując zadania wymagające wysoce wyspecjalizowanych umiejętności.
  • Atlassian również motywuje zewnętrznych testerów do identyfikowania luk w naszych produktach, oferując nagrody pieniężne w ramach naszego programu wykrywania błędów. Dzięki nim możemy skalować nasz zespół w znacznie większym stopniu niż jest to możliwe w przypadku tradycyjnego podejścia.
• W sprawie naszego programu testowania zabezpieczeń jesteśmy otwarci i transparentni — dostarczamy pisma potwierdzające przeprowadzenie ocen (LoA) dotyczące testów penetracyjnych przeprowadzanych na naszych produktach oraz statystyki dotyczące błędów znalezionych w naszym programie wykrywania błędów.

Zapewnianie bezpieczeństwa na bieżąco

Testy penetracyjne

W celu przeprowadzenia testów penetracyjnych naszych produktów i innych systemów korzystamy z usług specjalistycznych firm zajmujących się zabezpieczeniami. Oprócz tego nasz wewnętrzny zespół ds. testowania zabezpieczeń współpracuje z konsultantami zewnętrznymi w celu zapewnienia bezpieczeństwa technicznego projektów o wysokim priorytecie, takich jak nowa funkcja produktu (np. tablice Confluence), nowa konfiguracja infrastruktury (np. nasze środowisko FedRAMP) lub przeprojektowanie architektury (np. nowe środowisko uruchomieniowe Forge).

Nasze podejście do testów penetracyjnych w tych przypadkach jest ukierunkowane i skoncentrowane. Będą one obejmować:

• Testy strukturalne — testerzy otrzymają dokumentację projektową i omówienia od inżynierów ds. produktu, a w toku realizacji zadania będą mieli możliwość skontaktowania się z nimi w przypadku pytań związanych z testami.
• 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. Przykładowo można założyć, że doszło do naruszenia zabezpieczeń instancji, i prowadzić testy horyzontalnie od tak zdefiniowanego punktu wyjścia.
• Testy oparte na metodologii — testerzy używają szeregu scenariuszy dostosowanych do potrzeb testów strukturalnych w oparciu o uznane w branży metodologie, takie jak Open Web Application Security Project (OWASP). Dzięki temu testy uwzględniają zagrożenia unikatowe dla infrastruktury i technologii Atlassian.

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 uwzględniona w naszym publicznym programie wykrywania błędów, aby zapewnić ciągłość zewnętrznej kontroli. 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. Program ten zapewnia ciągłość testowania naszych produktów pod kątem luk w zabezpieczeniach.

Jesteśmy przekonani, że grono niezależnych testerów zabezpieczeń biorących udział w naszym programie wykrywania błędów przyczynia się do skutecznego funkcjonowania procesu zewnętrznego testowania zabezpieczeń, ponieważ:

• Program wykrywania błędów działa cały czas. Ciągłe testowanie jest niezbędne w środowisku programistycznym zgodnym z metodyką Agile, w którym nowe wydania pojawiają się często.
• Program wykrywania błędów zrzesza ponad 60 000 potencjalnych testerów. Połączenie umiejętności tych testerów stwarza duże możliwości w zakresie kontroli jakości.
• 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.

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 w chmurze. 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 2800 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).

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ą 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

Zezwalamy na testowanie inicjowane przez klientów zgodnie z naszymi Warunkami korzystania z naszych produktów w chmurze. 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 rozwiązaniu problemu i uwzględnieniu poprawki w wydaniu produkcyjnym. Wniosek zostanie jednak odrzucony, jeśli raport zawiera jakiekolwiek dane klienta. 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. Niektóre rodzaje luk w zabezpieczeniach niskiego ryzyka, takie jak związane z wyliczaniami i gromadzeniem informacji, na ogół nie są uważane za znaczące zagrożenia.

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.

Podsumowanie

Nasz program wykrywania błędów oparty na crowdsuourcingu, zaangażowanie zewnętrznych firm konsultingowych zajmujących się bezpieczeństwem i nasz wewnętrzny zespół ds. testowania zabezpieczeń składają się na kompleksowy, dojrzały i przejrzysty model. Gwarantuje to, że nasze produkty i platformy są stale testowane i zabezpieczane, dzięki czemu klienci mogą mieć pewność, że bezpieczeństwo naszych produktów jest poddawane ciągłej kontroli.

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. 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 (lipiec 2023 r.)
• Pobierz najnowszy raport z programu wykrywania błędów Halp (lipiec 2023 r.)
• Pobierz najnowszy raport z programu wykrywania błędów Jira Align (lipiec 2023 r.)
• Pobierz najnowszy raport z programu wykrywania błędów Opsgenie (lipiec 2023 r.)
• Pobierz najnowszy raport z programu wykrywania błędów Statuspage (lipiec 2023 r.)
• Pobierz najnowszy raport z programu wykrywania błędów Trello (lipiec 2023 r.)

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. 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 — Bitbucket Pipelines (maj 2022)
• Pismo potwierdzające przeprowadzenie oceny — Trello (sierpień 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 — 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)
• Pismo potwierdzające przeprowadzenie oceny — Jira Product Discovery (2023-03)
• Pismo potwierdzające przeprowadzenie oceny — Atlas (kwiecień 2023)
• Pismo potwierdzające przeprowadzenie oceny platformy wizualizacji Atlassian Analytics (maj 2023)
• Pismo potwierdzające przeprowadzenie oceny Confluence Server i Data Center (maj 2023)
• Pismo potwierdzające przeprowadzenie oceny serwera oraz centrum danych Fisheye i Crucible (maj 2023)
• Pismo potwierdzające przeprowadzenie oceny Jira Server i Data Center (maj 2023)
• Pismo potwierdzające przeprowadzenie oceny — Compass Cloud (maj 2023)
• Pismo potwierdzające przeprowadzenie oceny — Jira Align (czerwiec 2023)
• Pismo potwierdzające przeprowadzenie oceny — Atlassian Access (czerwiec 2023)
• Pismo potwierdzające przeprowadzenie oceny Crowd Server i Data Center (czerwiec 2023)
• Pismo potwierdzające przeprowadzenie oceny — Atlassian Assist (lipiec 2023)
• Pismo potwierdzające przeprowadzenie oceny – Bitbucket Server i DC (lipiec 2023)