Close
Czy wyświetlić tę stronę w Twoim języku?
Wszystkie języki
Wybierz swój język

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 wartości te doprowadziły nas do wypracowania następujących filozofii i sposobów podejścia:

  • 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 badacze 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 we wspólnym interesie — 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 badaczy do identyfikowania luk w zabezpieczeniach naszych produktów, 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 atestacji (LoA), dotyczące testów penetracyjnych przeprowadzanych na naszych produktach, oraz statystyki dotyczące błędów znalezionych za pośrednictwem naszego programu 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 atestacji (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 275 000 potencjalnych testerów z pond 100 krajó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.

Ponad 30 naszych produktów lub środowisk — w tym produkty sztucznej inteligencji, produkty chmurowe, produkty dala wersji Data Center i aplikacje mobilne — jest objętych naszym programem wykrywania błędów. 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 wzięło udział już ponad 3700 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 Marketplace są objęte opracowanym przez Atlassian programem wykrywania błędów w aplikacjach.

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, a także pisma potwierdzające przeprowadzenie atestacji (LoA).

Chociaż uważamy, że nasze podejście zapewnia kompleksową gwarancję bezpieczeństwa naszych produktów i usług, rozumiemy, że możesz woleć samodzielnie testować bezpieczeństwo. Zezwalamy klientom na przeprowadzanie ocen zabezpieczeń (testów penetracyjnych lub 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ń.

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.

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.

Pobieranie pism potwierdzających przeprowadzenie atestacji (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.