Nasze podejście do zewnętrznych testów zabezpieczeń
Witamy w naszym centrum testowania zabezpieczeń, którego celem jest dostarczanie wyczerpujących informacji na temat inicjatyw związanych z testowaniem zabezpieczeń wdrożonych przez Atlassian z myślą o zapewnieniu bezpieczeństwa i ochrony naszych produktów oraz klientów.
Szukasz czegoś konkretnego? Przyspiesz wyszukiwanie, korzystając z jednego z poniższych łączy, lub czytaj dalej, aby dokładniej poznać zewnętrzny program testowania zabezpieczeń Atlassian.
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 Data Center, 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 (październik 2024 r.)
- Pobierz najnowszy raport z programu wykrywania błędów Jira Align (październik 2024 r.)
- Pobierz najnowszy raport z programu wykrywania błędów Opsgenie (październik 2024 r.)
- Pobierz najnowszy raport z programu wykrywania błędów Statuspage (październik 2024 r.)
- Pobierz najnowszy raport z programu wykrywania błędów Trello (październik 2024 r.)
- Pobierz najnowszy raport z programu wykrywania błędów Loom (październik 2024 r.)
Pobieranie rocznego raportu z programów wykrywania błędów
Oprócz kwartalnych informacji dotyczących wykrytych błędów publikujemy też roczny raport z naszych programów wykrywania błędów. Klienci mogą dowiedzieć się w nim więcej o postępach programu i poznać szczegółowe opisy wykrytych luk w zabezpieczeniach.
- Pobierz raport Atlassian z programu wykrywania błędów za rok 2023 (lipiec 2022 – czerwiec 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. 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)
- List oceniający dla Atlassian Log4j Library for Confluence and Jira (2022-12)
- Pismo potwierdzające przeprowadzenie oceny — Statuspage Cloud (grudzień 2022)
- Pismo potwierdzające przeprowadzenie oceny — Atlas (kwiecień 2023)
- Pismo potwierdzające przeprowadzenie oceny — Atlassian Assist (lipiec 2023)
- Pismo potwierdzające przeprowadzenie oceny — Jira Service Management Data Center (grudzień 2023)
- Pismo potwierdzające przeprowadzenie oceny — Confluence Cloud (grudzień 2023)
- Pismo potwierdzające przeprowadzenie oceny — Trello (styczeń 2024)
- Pismo potwierdzające przeprowadzenie oceny — Bitbucket Cloud (luty 2024)
- Pismo potwierdzające przeprowadzenie oceny — Jira Work Management (luty 2024)
- Pismo potwierdzające przeprowadzenie oceny — Confluence Data Center (luty 2024)
- Pismo potwierdzające przeprowadzenie oceny — platforma Jira Cloud (marzec 2024 r.)
- Pismo potwierdzające przeprowadzenie oceny symulacji ataku zewnętrznego i wewnętrznego Atlassian (04.2024)
- Pismo potwierdzające przeprowadzenie oceny Bamboo Server i Data Center (maj 2024)
- Pismo potwierdzające przeprowadzenie oceny — Jira Product Discovery (2024-05)
- Pismo potwierdzające przeprowadzenie oceny — Atlassian Analytics (aplikacja internetowa) (czerwiec 2024)
- Pismo potwierdzające przeprowadzenie oceny — Atlassian Guard (czerwiec 2024 r.)
- Pismo potwierdzające przeprowadzenie oceny — Jira Software Data Center (czerwiec 2024)
- Pismo potwierdzające przeprowadzenie oceny serwera Fisheye i Crucible (aplikacja internetowa) (lipiec 2024 r.)
- Pismo potwierdzające przeprowadzenie oceny — Compass (aplikacja internetowa) (lipiec 2024 r.)
- Pismo potwierdzające przeprowadzenie oceny Crowd Server i Data Center (lipiec 2024)
- Pismo potwierdzające przeprowadzenie oceny — SourceTree (wrzesień 2024)
- Pismo potwierdzające przeprowadzenie oceny — Bitbucket Server i DC (wrzesień 2024)
- Pismo potwierdzające przeprowadzenie oceny — Forge (wrzesień 2024)
- Pismo potwierdzające przeprowadzenie oceny Jira Service Management, Opsgenie Cloud i AirTrack (wrzesień 2024)
- Pismo potwierdzające przeprowadzenie oceny — Jira Align (wrzesień 2024)
- Pismo potwierdzające przeprowadzenie oceny — Loom (październik 2024 r.)
- Pismo potwierdzające przeprowadzenie oceny — Atlassian Guard (aplikacja internetowa, wcześniej Beacon) (listopad 2024 r.)
- Pismo potwierdzające przeprowadzenie oceny — Rovo (listopad 2024 r.)