Bezpečný návrh software, pokračování AI zranitelností a další

Naučte se, jak navrhnout bezpečný software nebo jak zařadit bezpečnost do vývojového cyklu. Znáte membership inference a další AI zranitelnosti? Závažná Sentry zranitelnost a tisíce leaknutých credent

🏆 Téma: Bezpečná architektura software

• Ne v každé firmě, která vytváří software, je software architekt.

• Někteří software architekti nedbají na bezpečnost produktu.

  • Je to časově náročné, nemají dostatečné znalosti nebo není dostatečný budget.

• Z těchto důvodů se stává neúčinný návrh architektury čtvrtou nejčastější zranitelností současných webových aplikací.

Secure by design

• Metodika vývoje software - software je od začátku vývoje navržený tak, aby byl bezpečný.

• Každá část vývojového cyklu software (SDLC) obsahuje kroky, které zajistí jeho bezpečnost:

  • zapojení threat modelingu,

  • zajištění dokumentace,

  • neustálé ověřování a vyhodnocování hrozeb

  • atd.

• Minimální požadavky:

  • Každá user story by měla obsahovat požadavky na bezpečnost / zabezpečení.

  • Každý projekt by měl mít aktuální projektovou a API dokumentaci, threat model.

  • Software by měl být modulární, případně co nejvíce loosely coupled a cohesive.

  • Funkcionalita by měla být dostatečně logována a monitorována.

Jak zařadit bezpečnost do SDLC?

• Automatizujte vše, co jde.

  • Použijte statickou analýzu kódu pro testování zranitelností nebo lintery.

  • Použijte např. Dependabot pro automatické upgradování závislostí.

  • Pište automatické testy.

  • Vytvořte pipeline, která bude spouštět testy, build a další kontroly.

  • Použijte správce credentials a integrujte ho do pipeline.

  • Použijte např. Terraform k tvorbě infrastruktury.

  • atd.

• Zvyšte odhady při implementaci nové funkcionality - počítejte s bezpečnostními opatřeními.

• Postupně začněte psát technickou dokumentaci projektu a zaznamenávejte návrhová rozhodnutí a změny.

• Pravidelně na mítinku otevírejte téma zabezpečení a veďte si poznámky / úkoly jako výstup.

• Začněte se zajímat o OWASP top 10 (web, API, mobile…) a zabezpečte aplikaci proti těmto zranitelnostem.

• Vytvořte threat model pro každou novou funkcionalitu.

• Dělejte code review - nekontrolujte řádkování, case sensitivitu a další věci (to zvládne linter) - soustřeďte se na byznys logiku, návrhové vzory, výkon a zabezpečení.

  • Tzn. reviewer musí projekt znát - bez dostatečného kontextu nedokáže udělat kvalitní code review.

• Napište mi, rád vám s tím pomůžu. 🙂

🎓 Učíme se společně

Co jsme se dozvěděli z přednášek, školení, čtení knih a dalších aktivit?

AI zranitelnosti

Manipulace se vstupem

• Představte si, že máme auto, které dokáže rozpoznávat dopravní značky a reaguje na ně.

• Když vidí stopku, tak zastaví, když vidí značku zpomal, tak zpomalí atd.

• Co stane v případě, kdy se bílá dopravní značka, která říká "Zpomal na 50 km/h" přestříká červenou barvou?

• Zastaví auto, protože si myslí, že jde o stopku? Může se to stát.

• Vstup je možné měnit takovým způsobem, že model začne reagovat jinak, než je běžné.

• Tato technika je často používaná v souvislosti se spamem a phishingem.

• Útočník experimuntuje se slovy v emailu tak, aby oklamal klasifikátor spamu.

• Nejlepším způsobem ochrany proti této zranitelnosti je mít co nejrobustnější model.

Membership inference

• Zranitelnost může mít velký dopad na soukromí nás všech.

• Týká se hlavně citlivých údajů a osobních informací.

• Je však poměrně složitá na vysvětlení, protože vyžaduje hlubší znalost problematiky a kombinuje několik dalších zranitelností, aby se docílilo kýženého výsledku.

• Představte si nemocniční software, jehož úkolem je na základě fotek pacientů určovat, zda mají rakovinu, nebo ne.

• Model byl vytrénován na velkém množství fotek a nemocnice nesmí zveřejňovat záznamy o pacientech.

• Útočník může ale chtít vědět, zda jeden konkrétní člověk (např. Jana) náhodou nebyl v trénovací sadě a nemá rakovinu.

• Útočník ví, že nemocniční AI byla vytrénována na lidech, kteří mají rakovinu, resp. na jejich fotkách.

• Útočník takové fotky nemá, ale má spoustu fotek zdravých lidí.

• Vytrénuje tedy inverzní model, který umí rozpoznávat zdravé lidi.

• Pokud chce zjistit, zda má Jana rakovinu, "stačí", aby jeho model řekl, že není zdravá.

  • Příklad je velmi zjednodušený a samotný útok je složitější.

• Přesnost modelu útočníka se určuje porovnáním jeho odhadů se skutečnými štítky lékařských snímků.

• Pokud útočníkův model s velkou mírou pravděpodobnosti odhadne, zda byla konkrétní fotka použita k tréninku lékařského modelu, pak jde o úspěšný útok.

• Tento útok může mít vážné důsledky, protože daná osoba nemůže popřít, že je členem citlivé skupiny (ať už pacient s rakovinou nebo má určitou sexuální orientaci atd.).

• Čím víc se model učí rozpoznávat původní položky trénovací sady, tím větší vzniká problém.

• Tomu lze zabránit tím, že model bude malý a trénovací množina bude velká, nebo se do trénovací množiny přidá šum.

• Pokud vás zajímá AI bezpečnost a ochrana soukromí, přečtěte si můj článek, který se problematice věnuje.

📰 Co je nového

1. Další #haxing videa, aneb hackněte a opravte své zranitelnosti

   • Podívejte se, jak poslat zranitelnou zprávu přes formulář (Stored XSS).

   • Podívejte se, jak si zobrazit zdroják backend aplikace (API).

   • Podívejte se, jak vás někdo může hacknout zneužitím zranitelnosti třetí strany.

   • Sledujte Bezpečný kód na YouTube, ať vám neuniknou další videa.

2. API authentication bypass in Ivanti Sentry

   • Zranitelnost umožňovala přístup k admin API endpointu bez nutnosti přihlášení.

   • Endpoint umožňoval např. spouštění příkazů, změnu konfigurace nebo zápis do file systemu.

   • Zranitelnost je považována za kritickou a dostala hodnocení 9.8 z 10.

   • Společnost ji však považuje za málo pravděpodobnou, protože endpoint nebyl veřejně známý.

   • Pomocí sady skriptu a nastavení však problém vyřešili.

   • Jde o příklad druhé nejčastější API zranitelnosti “Selhání autentizace”.

3. Docker images expose APIs and private keys

   • report o rozšířenosti credentials a secrets uložených v docker obrazech

   • Každý desátý obraz v sobě obsahuje credentials.

   • 300.000 zkoumaných obrazů v sobě obsahuje:

     • 52.107 privátních klíčů,

     • 2.920 cloud credentials,

     • 213 klíčů k sociálním sítím,

     • 25 klíčů k finančním službám (Stripe, PayPal…).

   • Vývojáři mylně předpokládají, že přihlašovací údaje vložené do nižší vrstvy obrazu kontejneru nejsou přístupné.

   • Útočník může použít nástroj k rozbalení vrstev, nebo spustit shell v běžícím kontejneru, aby získal přístup k jakýmkoli secrets = kontejner není bezpečné paměťové médium.

   • Použijte například Vault nebo jiný sytém pro správu credentials, o kterém píšu v předchozím newsletteru.

---

😂 Závěrečný ftípek: Jaké jsou dvě největší obavy CISO v oblasti kybernetické bezpečnosti? Každý, kdo ve firmě pracuje… a každý, kdo tam nepracuje.

🙏 Vyplňte prosím zpětnou vazbu k newsletteru, ať je s každým vydáním lepší a lepší.

🔔 Sledujte nás na LinkedInu, kam pravidelně sdílíme další novinky a know-how.

🆘 S bezpečností vám rádi pomůžeme, klidně nám napište - školíme vývojáře i management, nastavujeme procesy, vyvíjíme bezpečné aplikace a poskytujeme další služby.