Koordynowane ujawnianie luk w zabezpieczeniach (CVD)

Gmina Apeldoorn przywiązuje dużą wagę do bezpieczeństwa swoich systemów. W ramach naszych działań na rzecz cyberbezpieczeństwa i ochrony naszych systemów zdajemy sobie sprawę z tego, jak ważne jest wykrywanie i zgłaszanie luk w zabezpieczeniach. CVD ma na celu zapewnienie ustrukturyzowanych ram, w których eksperci ds. bezpieczeństwa mogą zgłaszać luki w zabezpieczeniach.

W przypadku zgłoszenia CVD prosimy o następujące informacje

  • Zgłaszanie
    Prosimy o jak najszybsze zgłoszenie nam wykrytej luki w zabezpieczeniach. Sposób zgłaszania przedstawiono poniżej. Odkryte luki można zgłaszać organizacji wyłącznie w ten sposób.

    Prosimy o przesłanie Państwa ustaleń pocztą elektroniczną na adres cvd@apeldoorn.nl (do wykorzystania wyłącznie w przypadku zgłoszeń CVD). Wynik można również przesłać w bezpieczny i zaszyfrowany sposób za pośrednictwem strony internetowej https://crypt.apeldoorn.nl/.

  • Informacje
    Ponadto prosimy o przekazanie wystarczających informacji umożliwiających odtworzenie problemu, abyśmy mogli go szybko rozwiązać. Wystarczy podać adres IP lub adres URL danego systemu oraz opis problemu związanego z bezpieczeństwem. Dodatkowe istotne informacje i wskazówki są zawsze mile widziane, ponieważ mogą pomóc w szybszym rozwiązaniu problemu. Prosimy jednak unikać reklamowania konkretnych narzędzi (związanych z bezpieczeństwem).

    Informacji o problemie związanym z bezpieczeństwem nie należy udostępniać innym osobom, dopóki problem nie zostanie rozwiązany. Po jego rozwiązaniu możliwe jest opublikowanie informacji o tej luce w porozumieniu z zainteresowanymi stronami.

  • Kontakt
    Prosimy o podanie swoich danych kontaktowych, abyśmy mogli wspólnie pracować nad rozwiązaniem tego problemu. Prosimy o podanie co najmniej jednego adresu e-mail lub numeru telefonu. Dzięki temu nasze Centrum Operacji Bezpieczeństwa będzie mogło się z Państwem skontaktować.

Następujące czynności są zabronione

  • Umieszczenie złośliwe oprogramowanie.
  • To atak brute force dotyczące dostępu do systemów.
  • Korzystanie z inżynieria społeczna, chyba że okaże się to absolutnie konieczne w celu wykazania, że pracownik nie wywiązuje się z obowiązku starannego obchodzenia się z informacjami wrażliwymi.

Można to robić wyłącznie w sposób całkowicie zgodny z prawem, a więc nie poprzez szantaż ani inne nieuczciwe działania. Wyniki uzyskane w drodze socjotechniki powinny służyć wykryciu problemów związanych z bezpieczeństwem w procedurach i sposobie działania gminy, a nie wyrządzeniu szkody pracownikowi gminy.

  • Opublikowanie/ujawnienie luki w zabezpieczeniach przed jej usunięciem.
  • Wykonywanie zbędnych czynności wykraczających poza to, co jest absolutnie konieczne do zidentyfikowania i zgłoszenia problemu związanego z bezpieczeństwem. Pobieranie, modyfikowanie i usuwanie danych lub konfiguracji systemu jest zawsze zabronione.

Alternatywą jest utworzenie listy zawartości katalogu lub zrzutu ekranu.

  • Wykorzystywanie technik, takich jak atak typu DoS, które ograniczają dostępność i/lub funkcjonalność naszych systemów lub usług.

Czego jeszcze można się spodziewać

Aspekt prawny

  • Jeśli spełniają Państwo wszystkie powyższe warunki, nie wyciągniemy żadnych konsekwencji prawnych w związku z tym zgłoszeniem. Jeśli jednak okaże się, że naruszyli Państwo powyższe warunki, możemy mimo wszystko podjąć decyzję o wszczęciu postępowania sądowego przeciwko Państwu.

Kontakt w sprawie zgłoszenia

  • W ciągu 1 dnia roboczego wyślemy Państwu (automatyczne) potwierdzenie odbioru.
  • W ciągu trzech dni roboczych odpowiemy na Państwa zgłoszenie, przedstawiając (wstępną) ocenę wraz z przewidywaną datą rozwiązania sprawy.
  • Będziemy Państwa na bieżąco informować o postępach w sprawie zgłoszenia. Jak najszybciej usuniemy zgłoszony przez Państwa problem związany z bezpieczeństwem i dołożymy wszelkich starań, aby jego rozwiązanie nie trwało dłużej niż 30 dni. Często jesteśmy w tym zakresie uzależnieni od dostawców.

Rozpatrzenie Państwa sprawy i zgłoszenia

  • Traktujemy zgłoszenie jako poufne i nie udostępniamy Państwa danych osobowych bez Państwa zgody, chyba że jesteśmy do tego zobowiązani na mocy prawa lub orzeczenia sądowego.
  • Zawsze przekazujemy otrzymane zgłoszenia do Służby Bezpieczeństwa Informacyjnego dla gmin (IBD). W ten sposób zapewniamy, że gminy mogą dzielić się między sobą swoimi doświadczeniami w tej dziedzinie.
  • W drodze uzgodnień można ustalić, w jaki sposób informacja o luce w zabezpieczeniach zostanie opublikowana. Stanie się to dopiero po rozwiązaniu problemu.

Wynagrodzenie

  • W ramach podziękowania za pomoc możemy zaoferować Państwu wynagrodzenie. W zależności od powagi luki w zabezpieczeniach i jakości zgłoszenia nagroda ta może wahać się od zwykłego ‘dziękuję’ do kwoty maksymalnie 300 euro. Musi to być jednak dotychczas nieznana i poważna luka w zabezpieczeniach.

Gmina Apeldoorn może, w przypadku luk w zabezpieczeniach o niskim lub akceptowalnym ryzyku, podjąć decyzję o nieprzyznaniu nagrody za zgłoszenie. Poniżej przedstawiono kilka przykładów takich luk w zabezpieczeniach. Lista ta nie jest wyczerpująca.

  • Kody HTTP 404 lub inne kody inne niż HTTP 200.
  • Dodawanie zwykłego tekstu na stronach 404.
  • Banery z informacją o wersji w serwisach publicznych.
  • Pliki i foldery dostępne publicznie, zawierające informacje niewrażliwe.
  • Clickjacking na stronach bez funkcji logowania.
  • Certyfikaty z słabymi / przestarzałymi algorytmami szyfrowania.
  • Atak typu „cross-site request forgery” (CSRF) na formularzach dostępnych anonimowo.
  • Brak flag ‘secure’ / ‘HTTP Only’ w plikach cookie, które nie zawierają danych wrażliwych.
  • Korzystanie z metody HTTP OPTIONS.
  • Wstrzyknięcie nagłówka hosta.
  • Brak rekordów SPF, DKIM i DMARC.
  • Brak jednego lub kilku nagłówków bezpieczeństwa HTTP.
  • Obsługa funkcji ‘autouzupełniania’ lub ‘zapamiętywania hasła’. Nie wymuszono zabezpieczeń przed atakami typu brute force na formularz ‘zapomniałem hasła’ oraz w przypadku ‘zablokowania konta’.
  • Brak pytania potwierdzającego, takiego jak ponowne wprowadzenie hasła lub prośba o dodatkowe potwierdzenie e-mailowe.
  • Brak funkcji HTTP Public Key Pinning (HPKP).
  • Fałszowanie treści i wstawianie tekstu na stronach z komunikatem o błędzie.
  • Zgłaszanie starych wersji oprogramowania bez dowodu wykonalności (proof-of-concept) lub działającego exploita.
  • Wygasłe lub nieaktywne nazwy domen.
  • Same Site Scripting lub korzystanie za pośrednictwem reguły DNS dla localhost.
  • Brak DNSSEC.
  • Ewentualnie przestarzałe wersje serwerów lub aplikacji (pochodzących od podmiotów zewnętrznych) bez dowodów na to, że wersje te są podatne na ataki, oraz bez dowodów na wykorzystanie tej luki.
  • Ewentualnie przestarzałe wersje serwerów lub aplikacji (pochodzących od podmiotów zewnętrznych) bez dowodów na to, że wersje te są podatne na ataki, oraz bez dowodów na wykorzystanie tej luki.
  • Brakujące lub nieprawidłowo zastosowane nagłówki bezpieczeństwa HTTP, takie jak:
    • Strict-Transport-Security (HSTS).
    • HTTP Public Key Pinning (HPKP).
    • Polityka bezpieczeństwa treści (CSP).
    • X-Content-Type-Options.
    • X-Frame-Options.
    • X-WebKit-CSP.
    • X-XSS-Protection.

Niniejszy tekst został sporządzony zgodnie z wytycznymi Narodowego Centrum Cyberbezpieczeństwa (NCSC).