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)
Atlassian wyznacza docelowe poziomy świadczenia usług dotyczące usuwania luk w zabezpieczeniach na podstawie poziomu istotności problemów z zabezpieczeniami i konkretnego produktu. 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. Mają one również zastosowanie do rozwiązania Jira Align (zarówno w wersji Cloud, jak i w wersjach samodzielnie zarządzanych).
- Błędy krytyczne — usunięcie z produktu w ciągu 2 tygodni od zgłoszenia.
- Błędy bardzo istotne — usunięcie z produktu w ciągu 4 tygodni od zgłoszenia.
- Błędy średnio istotne — usunięcie z produktu w ciągu 6 tygodni od zgłoszenia.
- Błędy mało istotne — 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. 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 — usunięcie z produktu w ciągu 90 dni od zgłoszenia.
- Błędy mało istotne — 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:
|
Product | Back port policy | Example |
|---|---|---|
| Jira Software Server and Data Center Jira Core Server and Data Center Jira Service Management Server and Data Center (previously known as Jira Service Desk) Confluence Server and Data Center Bitbucket Server and Data Center | Issue new bug fix releases for:
| If a critical security bug fix is developed on 2020/01/01, the following are example releases that would receive the bug fix:
The following are examples of releases that would not receive new bug fix releases:
|
| We will only issue new bug fix releases for the current and previous feature release version. | For example, if a critical security bug fix is developed on 1 January 2020 for Bamboo, the following new bug fix releases would need to be produced:
|
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 będzie dążyć do wydania poprawki w terminach określonych w docelowych poziomach świadczenia usług wymienionych na początku tego dokumentu. 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.