Zasady usuwania błędów zabezpieczeń
Ochrona systemów klienta przed atakami z wykorzystaniem luk w zabezpieczeniach produktów Atlassian jest dla nas sprawą priorytetową.
Zakres
Poniżej opisano, w jaki sposób i kiedy usuwamy błędy zabezpieczeń w naszych produktach. Nie jest to opis pełnego procesu ujawniania lub doradztwa, który stosujemy.
Usuwanie błędów zabezpieczeń — docelowe poziomy świadczenia usług (SLO)
W przypadku wydawania poprawek zabezpieczeń w naszych produktach zdefiniowaliśmy następujące ramy czasowe:
Ramy czasowe usuwania błędów w trybie przyspieszonym
Przedstawione poniżej ramy czasowe dotyczą wszystkich produktów chmurowych Atlassian, a także dowolnego innego oprogramowania lub systemu zarządzanego przez Atlassian bądź działającego w oparciu o infrastrukturę Atlassian.
- Błędy krytyczne (wynik >= 8 wg CVSS wer. 2, wynik >= 9 wg CVSS wer. 3) — usunięcie z produktu w ciągu 2 tygodni od zgłoszenia
- Błędy bardzo istotne (wynik >= 6 wg CVSS wer. 2, wynik >=7 wg CVSS wer. 3) — usunięcie z produktu w ciągu 4 tygodni od zgłoszenia
- Błędy średnio istotne (wynik >= 3 wg CVSS wer. 2, wynik >= 4 wg CVSS wer. 3) — usunięcie z produktu w ciągu 6 tygodni od zgłoszenia
- Błędy mało istotne (wynik < 3 wg CVSS wer. 2, wynik < 4 wg CVSS wer. 3) — usunięcie z produktu w ciągu 25 tygodni od zgłoszenia
Ramy czasowe usuwania błędów w trybie wydłużonym
Przedstawione poniżej ramy czasowe dotyczą wszystkich samodzielnie zarządzanych produktów Atlassian oraz rozwiązania Jira Align (zarówno w wersji Cloud, jak i w wersjach samodzielnie zarządzanych). Produkt samodzielnie zarządzany jest instalowany przez klientów w systemach przez nich zarządzanych i obejmuje aplikacje serwerowe, do centrów danych, komputerowe i mobilne Atlassian.
- Błędy krytyczne, bardzo istotne i średnio istotne (wynik >= 3 wg CVSS wer. 2, wynik >= 4 wg CVSS wer. 3) — usunięcie z produktu w ciągu 90 dni od zgłoszenia
- Błędy mało istotne (wynik < 3 wg CVSS wer. 2, wynik < 4 wg CVSS wer. 3) — usunięcie z produktu w ciągu 180 dni od zgłoszenia
Krytyczne luki w zabezpieczeniach
W przypadku wykrycia przez Atlassian lub zgłoszenia przez stronę trzecią krytycznej luki w zabezpieczeniach, Atlassian podejmie następujące kroki:
- Możliwie jak najszybciej udostępni nowe, poprawione wydanie bieżącej wersji produktu, którego dotyczy problem.
- Opublikuje nowe wydanie poprawiające poprzednią wersję zgodnie z następującym schematem:
Produkt | Zasady backportowania | Przykład |
|---|---|---|
| Jira Software Server i Data Center Jira Core Server i Data Center Jira Service Management Server i Data Center (dawniej Jira Service Desk) | Udostępnienie nowych wydań z poprawką błędu dla:
| Przykładowo, jeśli krytyczna poprawka zabezpieczeń została opracowana 1 stycznia 2020 roku, konieczne będzie utworzenie następujących nowych wydań z poprawką błędu:
|
| Confluence Server i Data Center | Udostępnienie nowych wydań z poprawką błędu dla:
| Przykładowo, jeśli krytyczna poprawka zabezpieczeń została opracowana 1 stycznia 2020 roku, konieczne będzie utworzenie następujących nowych wydań z poprawką błędu:
|
| Bitbucket Server i Data Center | Udostępnienie nowych wydań z poprawką błędu dla:
| Przykładowo, jeśli krytyczna poprawka zabezpieczeń została opracowana 1 stycznia 2020 roku, konieczne będzie utworzenie następujących nowych wydań z poprawką błędu:
Bitbucket 6.3.0 wydano 14 maja 2019 roku, ponad sześć miesięcy przed datą poprawki. Gdyby ta wersja była oznaczona jako wersja ze wsparciem długoterminowym, utworzono by również wydanie z poprawką błędu. |
| Udostępnienie nowych wydań z poprawką błędu jedynie dla bieżącej i poprzedniej wersji wydania z funkcjami. | Przykładowo, jeśli krytyczna poprawka zabezpieczeń dla rozwiązania Bamboo została opracowana 1 stycznia 2020 roku, konieczne będzie utworzenie następujących nowych wydań z poprawką błędu:
|
ProduktJira Software Server i Data Center Jira Core Server i Data Center Jira Service Desk Server i Data Center |
Zasady backportowaniaUdostępnienie nowych wydań z poprawką błędu dla:
|
PrzykładPrzykładowo, jeśli krytyczna poprawka zabezpieczeń została opracowana 1 stycznia 2020 roku, konieczne będzie utworzenie następujących nowych wydań z poprawką błędu:
|
ProduktConfluence Server i Data Center |
Zasady backportowaniaUdostępnienie nowych wydań z poprawką błędu dla:
|
PrzykładPrzykładowo, jeśli krytyczna poprawka zabezpieczeń została opracowana 1 stycznia 2020 roku, konieczne będzie utworzenie następujących nowych wydań z poprawką błędu:
|
ProduktBitbucket Server i Data Center |
Zasady backportowaniaUdostępnienie nowych wydań z poprawką błędu dla:
|
PrzykładPrzykładowo, jeśli krytyczna poprawka zabezpieczeń została opracowana 1 stycznia 2020 roku, konieczne będzie utworzenie następujących nowych wydań z poprawką błędu:
Bitbucket 6.3.0 wydano 14 maja 2019 roku, ponad sześć miesięcy przed datą poprawki. Gdyby ta wersja była oznaczona jako wersja ze wsparciem długoterminowym, utworzono by również wydanie z poprawką błędu. |
Produkt |
Zasady backportowaniaUdostępnienie nowych wydań z poprawką błędu jedynie dla bieżącej i poprzedniej wersji wydania z funkcjami. |
PrzykładPrzykładowo, jeśli krytyczna poprawka zabezpieczeń dla rozwiązania Bamboo została opracowana 1 stycznia 2020 roku, konieczne będzie utworzenie następujących nowych wydań z poprawką błędu:
|
Ważne, aby korzystać z najnowszego wydania z poprawkami błędów używanej wersji produktu (jest to najlepsza praktyka). Przykładowo klienci korzystający z rozwiązania Jira Software 7.5.0, powinni proaktywnie dokonać uaktualnienia do wersji Jira Software 7.5.3. W przypadku wydania nowej poprawki zabezpieczeń, np. Jira Software 7.5.4, różnica między dwoma wersjami będzie minimalna (tj. będzie to wyłącznie poprawka zabezpieczeń), co ułatwi jej zastosowanie.
Proces eliminowania krytycznych luk w zabezpieczeniach nie ma zastosowania do produktów Atlassian Cloud, ponieważ poprawki w tych usługach są zawsze wprowadzane przez Atlassian, bez konieczności podejmowania jakichkolwiek działań przez klientów.
Niekrytyczne luki w zabezpieczeniach
W przypadku wykrycia bardzo istotnych, średnio istotnych lub mało istotnych problemów z zabezpieczeniami Atlassian uwzględni poprawkę w następnym zaplanowanym wydaniu. Jeśli jest to wykonalne, możliwe jest również backportowanie poprawki do wersji ze wsparciem długoterminowym.
Po udostępnieniu wydania z poprawką błędu należy uaktualnić instalacje, aby mieć pewność, że zostały zastosowane najnowsze poprawki zabezpieczeń.
Inne informacje
Poziom istotności luk w zabezpieczeniach jest obliczany na podstawie poziomów istotności problemów z zabezpieczeniami.
Będziemy poddawać nasze zasady ciągłej ewaluacji w oparciu o opinie klientów, a na tej stronie będziemy zamieszczać wszelkie aktualności lub zmiany.