JAK DALEKO JSTE OD PŘÍLOHY I?

Písmeno g) je minimalizace údajů: produkt smí zpracovávat jen údaje přiměřené, relevantní a omezené na to, co je nezbytné ve vztahu k jeho zamýšlenému účelu. Nejčastěji na tom padá telemetrie a diagnostika, které sbírají „pro jistotu“ víc, než k čemu má produkt důvod.

Písmeno h) chce ochranu dostupnosti základních a klíčových funkcí, a to i po incidentu, opatřeními ke zvýšení odolnosti vůči útokům na odepření služby a ke zmírnění jejich dopadu. Typicky jde o omezení počtu požadavků, o chování při zahlcení a o to, jestli se produkt sám vrátí do provozu.

Písmeno i) žádá minimalizaci vlastního nepříznivého dopadu produktu — i dopadu připojených zařízení — na dostupnost služeb poskytovaných jinými zařízeními nebo sítěmi. Cílem je, aby se z produktu nestal zdroj provozu, který položí síť zákazníka, ať už chybou, nebo po kompromitaci.

Písmeno j) chce návrh, vývoj a výrobu tak, aby byly omezené prostory k útoku, včetně vnějších rozhraní. Prakticky jde o vypnuté nepoužívané služby a porty, žádné ladicí a servisní vstupy v produkční verzi a co nejmenší počet komponent, které je nutné udržovat.

Písmeno k) žádá návrh, vývoj a výrobu tak, aby se snížil dopad incidentu použitím vhodných mechanismů a technik zmírňujících zneužití — tedy toho, co útočníkovi po nalezení chyby ztíží její využití nebo omezí, kam se dostane. Patří sem ochrany překladu a běhového prostředí, oddělení procesů a oprávnění a izolace komponent.

Písmeno l) chce, aby produkt poskytoval informace související s bezpečností: zaznamenával a kontroloval příslušnou interní činnost včetně přístupu k údajům, službám nebo funkcím a jejich změn, s možností využít mechanismus výjimky pro uživatele. Bez těchhle záznamů se u incidentu nedá zjistit, co se stalo — a hlášení podle čl. 14 pak nemá z čeho vycházet.

Písmeno m) žádá možnost bezpečně a snadno natrvalo odstranit všechny údaje a nastavení, a pokud je lze přenést do jiných produktů nebo systémů, aby se tak dělo bezpečným způsobem. Je to funkce, na kterou se zákazník ptá při vyřazení zařízení z provozu i při jeho předání dál.

Bod 1 chce určit a zdokumentovat zranitelnosti a komponenty obsažené v produktu, mimo jiné vypracováním softwarového kusovníku (SBOM) v běžně používaném strojově čitelném formátu, který obsahuje přinejmenším nejdůležitější závislosti produktu. Ruční tabulka požadavek formálně splní jednou; udržitelný je jen kusovník, který vzniká z buildu.

Bod 2 žádá neprodlené řešení a odstraňování zranitelností v souvislosti s riziky, která pro produkt představují, mimo jiné poskytováním bezpečnostních aktualizací; je-li to technicky možné, mají být bezpečnostní aktualizace poskytovány odděleně od funkčních. Odděleně proto, aby si zákazník mohl vzít opravu, aniž by musel přijmout novou funkcionalitu.

Bod 3 chce účinné a pravidelné testy a pravidelný přezkum bezpečnosti produktu. Metodu ani frekvenci nepředepisuje — ty plynou z posouzení rizik — ale předpokládá opakovatelnost a záznam. Jednorázový test před uvedením na trh požadavek nesplní.

Bod 4 žádá, aby výrobce po zveřejnění bezpečnostní aktualizace poskytl a uveřejnil informace o opravených zranitelnostech: popis, údaje umožňující uživatelům zjistit dotčený produkt, dopad, závažnost a jasné informace, které jim pomohou zranitelnost odstranit. Zveřejnění lze v řádně odůvodněných případech odložit do doby, kdy uživatelé mohou opravu použít.

Bod 5 žádá zavést a prosazovat politiku koordinovaného zveřejňování zranitelností. Znamená to napsané a veřejné pravidlo, jak se naloží s hlášením zvenčí: kdo ho přijme, do kdy se ozve, jak se řeší a kdy se informace zveřejní. Doklad o ní patří do technické dokumentace (příloha VII bod 2 písm. b).

Bod 6 chce opatření ke snadnějšímu sdílení informací o možných zranitelnostech produktu i komponent třetích stran v něm obsažených, mimo jiné poskytnutí kontaktní adresy pro oznamování. Na totéž kontaktní místo odkazuje příloha II — patří mezi informace přikládané k produktu, takže musí být dohledatelné bez znalosti interní struktury firmy.

Bod 7 žádá stanovit mechanismy pro bezpečnou distribuci aktualizací tak, aby zranitelnosti byly včas opraveny nebo zmírněny, a aby se tak u bezpečnostních aktualizací dělo automaticky, je-li to možné. Bezpečná distribuce znamená ověřený původ a integritu balíčku a odolnost proti podvržení i proti návratu na starší verzi. Popis zvoleného technického řešení patří do technické dokumentace (příloha VII bod 2 písm. b).

Bod 8 chce, aby se dostupné bezpečnostní aktualizace šířily neprodleně a bezplatně spolu s poradními zprávami, které uživatelům řeknou, co se stalo a co mají udělat. Jinou dohodu připouští jen u produktu zhotoveného na zakázku a jen s podnikatelským uživatelem. Placená podpora tedy existovat může, ale nesmí být podmínkou pro získání bezpečnostní opravy.