aitech-pbr2022/09_zarzadzanie_bezpieczenstwem_aplikacji.ipynb

Zarządzanie bezpieczeństwem aplikacji

9. Projekt badawczo-rozwojowy [wykład]

Tomasz Kowalski (2022)

Infrastruktura krytyczna

(...) to rzeczywiste i cybernetyczne systemy (obiekty, urządzenia bądź instalacje) niezbędne do minimalnego funkcjonowania gospodarki i państwa. (źródło: RCB)

1. Energia (prąd elektryczny, paliwo)
2. Łączność (telefon, internet)
3. Finanse (karta płatniczna, bankowość elektroniczna)
4. Żywność
5. Woda

oraz wiele innych składników tzw. infrastruktury krytycznej to są Twoje zależności (ang. dependencies)

Infrastruktura krytyczna to, według ustawy o zarządzaniu kryzysowym, systemy oraz wchodzące w ich skład powiązane ze sobą funkcjonalnie obiekty, w tym obiekty budowlane, urządzenia, instalacje, usługi kluczowe dla bezpieczeństwa państwa i jego obywateli oraz służące zapewnieniu sprawnego funkcjonowania administracji publicznej, a także instytucji i przedsiębiorców.

Teraz warto zrealizować zadanie 1.

Typowy stos aplikacyjny

1. Aplikacja
2. Middleware
3. Userspace
4. Kernel
5. Bootloader
6. Hypervisor
7. Firmware
8. BIOS | EFI
9. CPU | Management Engine

Czy masz świadomość zależności Twojej aplikacji na drugiej i kolejnych warstwach?

Teraz warto zrealizować zadanie 2.

Teraz warto zrealizować także zadanie 3.

Jakie są współczesne aplikacje?

Fikcyjny stos, ale (niestety) ze znajomymi elementami

Humor (w różnych postaciach) jest tym środkiem, z użyciem którego wyraża się prawdy, które wypowiedziane wprost byłby trudne do przyjęcia.

Popatrzmy na XKCD 1636.

Jeśli odniesienia obecne w tej grafice nie są czytelne to można podeprzeć się objaśnieniem.

Do przemyślenia. Być może pracujesz przy młodym projekcie lub produkcie i jego konstrukcja jest czytelna, a każdy element ma opiekuna. Jednak jeśli pracujesz przy produkcie, który ma już pewną historię, to czy dostrzegasz w nim miejsca, które zrealizowane są w nieoczywisty lub przestarzały sposób? Jeśli tak to jest w zespole ktoś kto opiekuje się tym elementem? (A może autorzy tego rozwiązania już przy tym produkcie nie pracują i nikt nie przejął opieki na tym elementem?)

Rzeczywisty "stos" - przkład: linux w przeglądarce

Niestety żart w informatyce potrafi przerodzić się w rzeczywistość.

Już w 2011 kernel linuksowy pracował wewnątrz przeglądarki. Tylko dlaczego?! (Po co?)

Jest 2022 i temat nadal jest aktualny.

Mało tego - rzecz zdaje się eskalować, gdyż w ramach emulacji można już uruchomić kompletny system, a samo jądro przeportowano i pracuje w przeglądarce natywnie.

Do przemyślenia. Niegdyś napisanie aplikacji desktopowej w ten sposób, że jest to tzw. webówka działająca na localhost w zakamuflowanej przeglądarce (bez paska narzędzi, bez paska adresu, itp.) wydawało się żartem, a dziś [Electron](https://www.electronjs.org/) (i podobne frameworki) nikogo nie dziwią (a użytkownicy Atom, GitHub Desktop, Light Table, Visual Studio Code, WordPress Desktop czy Eclipse Theia, często nie wiedzę jak one są skonstruowane).

Jak radzimy sobie z utrzymaniem i rozwojem oprogramowania w dłuższej perspektywie?

Humorystyczne, ale prawdziwie, ujmuje to Geek&Poke 2011/3/1

Rzeczywistość, w której stare i słabe komponenty próbuje się "maskować", dobrze przedstawia historia Synactive na pwn2own 2021.

Uwaga do zapamiętania. To już jest zarządzanie bezpieczeństwem jednak w wariancie, który trudno z czystym sumieniem polecić.

Można zrozumieć, że są pewne zależności, których niesposób zmienić (z powodu kosztów, skali problemu, itp.) jednak ogólnie obfuskacją nie można przykryć niedomagań systemu operacyjnego pozbawionego współczesnych środków bezpieczeństwa.

Zamaskowania problemu to zwykle (a w dłuższej perspektywie - zawsze) zły pomysł.

Zapobieganie powstawaniu błędów

Dla ops-ów mamy

CIS Microsoft Windows 11 Enterprise Benchmark

CIS Distribution Independent Linux Benchmark

i wiele wiele innych

Dla dev-ów mamy

OWASP Secure Coding Practices

SEI Secure Coding Standards

BDEW Whitepaper Requirements for Secure Control and Telecommunication Systems

CIS Application Software Security

CIS Software Supply Chain

ale także

ISO 27002

ISO 27019

Literatura. Powyższe pozycje należy traktować jak wskazanie dalszej lektury po tym wykładzie. Jeśli same dokumenty źródłowe okażą się niewystarczające to posługując się ich nazwami można wyszukać wtórne opracowania.

Przykład: OWASP SCP Quick Reference Guide

(link był wcześniej: Zapobieganie powstawaniu błędów -> Dla dev-ów)

Obecnie v2

11.2010 (niby stare, ale wątpię czy cokolwiek z tego można spokojnie pominąć)

PDF ma zaledwie 17 stron:

• checklist-a dobrych praktyk (str. 5-13)
• walidacja wejścia
• encoding wyjścia
• autentykacja i zarządzanie hasłami
• zarządzanie sesją
• kontrola dostępu
• praktyki kryptograficzne
• obsługa błędów i logowania
• ochrona danych
• bezpieczeństwo komunikacji
• konfiguracja systemu
• bezpieczeństwo związane z obsługą bazy danych
• zarządzanie plikami
• zarządzanie pamięcią
• ogólnie, praktyki programistyczne
• elementarny słownik pojęć związanych z bezpieczeństwem (str. 15-17)

Teraz warto zrealizować zadanie 4.

Stos zagrożeń (~ISO OSI RM)

Każdy słyszał o modelu referencyjnym ISO OSI, ale o tym, że można go zamapować na stos tzw. thread actors, już nie każdy.

Teraz warto zrealizować zadanie 5.

Kwestia tzw. credentials

Czyli API keys, username/passwd, certificates, …

Do przemyślenia. Gdzie są “credentials” do tych wszystkich systemów i usług, które wykorzystujecie w projekcie lub produkcie?

• Kto ma do nich dostęp?
• Jak je otrzymali?
• Gdzie są przechowywane?
• Gdzie są używane?

Drogi Programisto, czy jest coś cenniejszego niż kod źródłowy? Kod jest czymś co lub wyciekać, a to przecież cały majątek Twojej firmy.

Problem wyciekania kodu i różnego rodzaju "credentials" jest tak duży, że doczekał się własnego określenia - jest to tzw. "secret sprawl". Szczegóły np. w tegorocznym w raporcie Gitguardian

Literatura. Powyższa pozycja to wskazanie dalszej lektury po tym wykładzie.

Do przemyślenia. Czy wśród zależności Twojego projektu lub produktu znalazł się używany przez Ciebie VSC? Jak go chronisz?

Jak poznać czy jest dobrze czy już źle?

Pasażerowie płonącego samolotu potrafią zachować się jakby nic nietypowego się nie wydarzyło. A jak Ty poznasz, że coś poszło nie tak?

Użyj kanarka!

Literatura. Powyższa pozycja to wskazanie dalszej lektury po tym wykładzie.

Teraz warto zrealizować zadanie 6.

Zabezpieczenie linii produkcyjnej oprogramowania i łańcucha dostaw

Usterki w zakresie bezpieczeństwa mogą pojawić się na każdym etapie rozwoju oprogramowania:

• (już na starcie) nie zidentyfikowano wymagań dot. bezpieczeństwa
• stworzono projekt (ang. design), który ma błędy logiczne
• kiepska kultura kodowania poskutkowała wadami technicznymi (a więc podatnościami)
• wdrożenie (ang. deployment) było … niewłaściwe
• (na koniec, a więc ang. maintenance) zaktualizowano o nowe błędy

Zapobieganie? Np. CIS Software Supply Chain Security Guide

obecnie v1

świeżynka (10/2022)

PDF ma 66 stron, 100+ rekomendacji:

• Kod źródłowy
• zmiany w kodzie
• zarządzanie repozytorium
• uprawnienia do modyfikacji kodu
• dostęp dla stron trzecich
• ryzyka związane z kodem
• Build pipelines
• środowisko
• worker
• budowa pipeline
• integralność pipeline
• Zależności
• pakiety stron trzecich
• walidacja pakietów
• Artefakty
• weryfikacja
• dostęp do nich
• ich repo
• śledzenie pochodzenia
• Wdrożenie
• środowisko
• konfiguracja

Podsumowanie

To nie ludzie z operations kształtują bezpieczeństwo. To jakość pracy programisty wyznacza jego poziom.

Zarządzanie bezpieczeństwem polega na tym, aby właściwym ludziom "się chciało".

Zarządzanie bezpieczeństwem coś jakby BHP (fabryka dla niepoznaki zwana jest software house).

Zarządzanie bezpieczeństwem polega na podejmowaniu trudnych decyzji (czas, pieniądze, itp.), które wpływają na kształt projektu, wartość produktu i odciskają piętno na jakości życia użytkowników.

Powoli zmierzamy w stronę standaryzacji np. Supply-chain Levels for Software Artifacts (SLSA) lub The Update Framework (TUF).

Ludzie z operations nie zarządzają bezpieczeństwem. Ponieważ produkty są takie jakimi wypuścili je programiści to w operations mamy już tylko "vulnerability management".

Propozycje zadań na laboratorium

Zadanie 1. Od czego zależy Twoja aplikacja lub projekt?

Przypomnij sobie którykolwiek ze swoich projektów. Co jest niezbędne dla jego prawidłowego funkcjonowania? (Także w dłuższej perspektywie czasowej).

Podaj nazwy. (Np. biblioteki, systemu, usługi, narzędzia, sprzętu, …)

Kliknij aby wrócić do właściwego miejsca w wykładzie

Zadanie 2. Od czego w nieoczywisty sposób zależy Twoja aplikacja lub projekt?

Przyjrzyj się projektowi lub produktowi nad którym pracujesz. Spójrz na "typowy stos aplikacyjny" i dla każdej z warstw (drugiej warstwy i kolejnych) wskaż właściwy projekt lub produkt. To też są Twoje zależności.

Zadanie 3. Jak dojrzałe są Twoje zależności?

Dla każdego projektu lub produktu zidentyfikowanego w poprzednim zadaniu 2 odszukaj informację o choć jednej podatności (ang. vulnerability).

Informacja o jak najmłodszych podatnościach jest najcenniejsza. Czy Ty lub Twój zespół podjęliście już właściwe środki zaradcze?

Informacja o starszych podatnościach również jest wartościowa. Skąd wiesz, że te problemy już nie występują? Co jest źródłem tej pewności? Co sądzisz o jakości tego projektu lub produktu patrząc na ilość i typ zidentyfikowanych podatności?

Kliknij aby wrócić do właściwego miejsca w wykładzie

Zadanie 4. Zgodność z zaleceniami OWASP.

W zespole - przyłóżcie tych 214 zaleceń OWASP do swojego projektu; ile z nich już spełniacie?

Kliknij aby wrócić do właściwego miejsca w wykładzie

Zadanie 5

Przyjrzyj się XKCD 2166 i dla każdej z warstw na tym stosie odszukaj informacje o choćby jednej:

• zidentyfikowanej podatności tego typu
• lub doniesienia prasowe np. o głośnych incydentach w tym zakresie.

Jeśli w przypadku niższych warstw nie wiesz gdzie zacząć to zerknij na objaśnienie do komiksu.

Kliknij aby wrócić do właściwego miejsca w wykładzie

Zadanie 6

Utwórz na Github publiczne repo. Stwórz w nim “fejkowy” projekt - trochę kodu, jakiś config.

Wygeneruj kanarka - klucz AWS. Dopisz go w configu, zacommituj, pchnij.

Zjedz kanapkę, wypij kawę, … a po chwili z przerażeniem obserwuj co by to było, gdyby to był faktyczny klucz.

Kliknij aby wrócić do właściwego miejsca w wykładzie