Představte si, že vaše firma investuje miliony do firewallů, EDR, SIEM a bezpečnostních školení. A pak útočník získá přístup přes software pro správu IT, který používáte — software, kterému jste ze své podstaty museli dát administrátorská práva k celé infrastruktuře. Přesně tak fungoval útok na SolarWinds v roce 2020, který zasáhl přes 18 000 organizací včetně amerických vládních agentur.
Supply chain útoky (útoky na dodavatelský řetězec) jsou zákeřné právě proto, že exploitují důvěru. Útočník nemusí překonávat vaši obranu — projde branami, která jste sami otevřeli pro legitimitního dodavatele.
Anatomie supply chain útoku: Jak fungují
Supply chain útok je kompromitace softwaru, hardwaru nebo služby, která je následně použita k útoku na zákazníky dodavatele. Existuje několik základních vzorů:
Kompromitace softwarového update mechanismu (SolarWinds)
Ruská skupina APT29 (Cozy Bear) infiltrovala build pipeline SolarWinds a vložila malware (Sunburst backdoor) přímo do legitimní aktualizace platformy Orion. Zákazníci, kteří automaticky aplikovali aktualizace — jak jim bylo doporučováno — si tím nainstalovali backdoor. Malware byl přítomen v systémech měsíce, než byl odhalen, a útočníci měli volný přístup ke kritické infrastruktuře obětí.
Klíčový poznatek: digitální podpis aktualizace byl platný, protože malware byl vložen před podpisem. Tradiční bezpečnostní kontroly to neodhalily.
Záměrná sabotáž open-source projektu (XZ Utils 2024)
Případ XZ Utils z roku 2024 ukázal jinou dimenzi hrozby. Útočník (operující pod pseudonymem JiaT75) po dobu téměř dvou let systematicky budoval důvěru v komunitě open-source projektu XZ Utils — kompresní knihovny přítomné prakticky v každé linuxové distribuci. Poté vložil záměrně obfuskovaný backdoor do release verze, který by umožnil neautorizovaný SSH přístup k systémům s nainstalovanou verzí 5.6.0 nebo 5.6.1. Útok byl odhalen náhodou těsně před masovým nasazením do distribucí.
Kompromitace open-source balíčků (typosquatting, dependency confusion)
Méně sofistikované, ale velmi rozšířené útoky cílí na npm, PyPI a další balíčkové registry. Útočníci nahrají balíček s podobným názvem (typosquatting: reqeusts místo requests) nebo využijí dependency confusion — nahrání veřejného balíčku se stejným názvem jako interní privátní balíček firmy s vyšším číslem verze.
Třetí strany jako vektor útoku: Co vás ohrožuje
Nejde jen o software. Supply chain rizika přicházejí z mnoha směrů:
- Managed Service Providers (MSP): IT firmy s administrátorským přístupem k vaší infrastruktuře jsou extrémně atraktivním cílem — útočník kompromituje jednoho MSP a získá přístup ke stovkám jeho zákazníků najednou (případ Kaseya 2021).
- SaaS aplikace třetích stran: CRM, HR systémy, účetní software — tyto aplikace mají přístup k citlivým firemním datům a jejich API jsou propojeny s vaší infrastrukturou.
- Hardware a firmware: kompromitace firmware routerů nebo serverů na úrovni výrobního procesu nebo distribučního řetězce. Čínské regulace ukládají výrobcům spolupráci s vládou, což vytváří geopolitické riziko.
- Lidský faktor: konzultanti, dočasní pracovníci nebo zaměstnanci dodavatele s přístupem k vašim systémům.
NIS2 a bezpečnost dodavatelského řetězce
NIS2 směrnice explicitně adresuje rizika dodavatelského řetězce v článku 21. Povinné subjekty musí zavést bezpečnostní opatření zahrnující bezpečnost dodavatelského řetězce a vztahů s třetími stranami. To není doporučení — je to zákonná povinnost.
Konkrétně to znamená:
- Identifikovat a zdokumentovat závislosti na třetích stranách (software, hardware, služby).
- Provádět hodnocení bezpečnostní úrovně klíčových dodavatelů.
- Smluvně ukotvit bezpečnostní požadavky vůči dodavatelům.
- Monitorovat bezpečnostní incidenty u dodavatelů a být informován o jejich výskytu.
Nesplnění těchto požadavků může vést k pokutám až 10 milionů EUR nebo 2 % celosvětového obratu — přičemž zodpovědnost nelze delegovat na dodavatele. Je to vaše riziko.
Jak hodnotit dodavatele: Praktický postup
Kategorizace dodavatelů dle kritičnosti
Ne všichni dodavatelé jsou stejně rizikoví. Začněte klasifikací:
- Kritičtí dodavatelé (Tier 1): přímý přístup k vaší infrastruktuře, zpracovávají citlivá data nebo jsou nezbytní pro kontinuitu provozu. Příklady: MSP, cloudové platformy, ERP systémy.
- Důležití dodavatelé (Tier 2): nepřímý přístup k datům, SaaS aplikace, vývojářské nástroje.
- Ostatní dodavatelé (Tier 3): minimální přístup k systémům nebo datům.
Bezpečnostní due diligence
Pro Tier 1 a Tier 2 dodavatele provádějte:
- Dotazník bezpečnostní úrovně (SIG — Standardized Information Gathering Questionnaire nebo CAIQ).
- Žádost o bezpečnostní certifikace: ISO 27001, SOC 2 Type II, Cyber Essentials Plus.
- Přezkoumání penetračních testů a výsledků bezpečnostních auditů (pod NDA).
- Kontrolu zásad pro správu zranitelností a patch managementu.
- Ověření, jak dodavatel řeší bezpečnostní incidenty a zda má vlastní IR plán.
Smluvní bezpečnostní požadavky
Každá smlouva s kritickým dodavatelem by měla obsahovat:
- Povinnost hlásit bezpečnostní incidenty do 24–72 hodin od jejich zjištění.
- Právo na audit nebo třetí strany bezpečnostní assessment.
- Požadavky na minimální bezpečnostní standardy (šifrování dat, správa přístupů, MFA).
- Podmínky pro sub-dodavatele — průchod vašich bezpečnostních požadavků do celého řetězce.
- Postup při ukončení spolupráce: mazání dat, revokace přístupů, předání dokumentace.
- Smluvní pokuty nebo právo na ukončení smlouvy při závažném bezpečnostním selhání.
Technická opatření pro ochranu před supply chain útoky
Smluvní a procesní opatření nestačí — potřebujete také technické zábrany:
- Software Bill of Materials (SBOM): vyžadujte od dodavatelů softwaru SBOM — seznam všech komponent a závislostí. Umožňuje rychle identifikovat, zda vámi používaný software obsahuje zranitelnou komponentu (jako Log4Shell v roce 2021).
- Code signing a verifikace integrity: ověřujte digitální podpisy všech softwarových aktualizací. Pro kritické systémy implementujte detailní hash verifikaci dodávaných binárních souborů.
- Dependency monitoring: nástroje jako Dependabot, Snyk nebo OWASP Dependency-Check průběžně sledují vaše open-source závislosti a upozorní na CVE.
- Zero Trust architektura: i důvěryhodní dodavatelé by měli mít přístup jen k tomu, co nezbytně potřebují. Microsegmentace, just-in-time přístupy, nepřetržité ověřování identity.
- Monitoring aktivity třetích stran: logujte a analyzujte aktivitu externích přístupů — anomálie (přístup mimo pracovní dobu, neobvyklé množství dat) mohou indikovat kompromitaci.
Sestavení uceleného programu řízení bezpečnosti třetích stran je komplexní projekt. SecureOn.cz pomáhá organizacím s inventarizací dodavatelů, jejich hodnocením a nastavením smluvních a technických opatření v souladu s NIS2.
Závěr: Bezpečnost je tak silná jako nejslabší článek řetězce
Supply chain bezpečnost není nadstandard — je to základní podmínka pro zvládnutí moderního hrozebného prostředí. Útočníci jsou pragmatičtí: útočí tam, kde je nejnižší odpor. Pokud vaši přímí dodavatelé nemají adekvátní bezpečnostní úroveň, stávají se vaším nejslabším článkem.
Začněte tím, co je proveditelné: zmapujte kritické závislosti, vyžádejte si bezpečnostní certifikace od klíčových dodavatelů a zapracujte základní požadavky do nových smluv. Postupně budujte komplexní program. NIS2 vám k tomu dává jak povinnost, tak i rámec.