nukib / bezpecnostni-doporuceni-open-source Goto Github PK

Tento dokument vzniká jako doporučení pro veřejný sektor, a v něm lze očekávat i cizojazyčně mluvící zaměstnance a vývojáře. Aby mohly firmy tento dokument používat a čerpat z něj dlouhodobě, doporučoval bych poskytnout i jeho anglický překlad, alespoň v březnu po dokončení první finální verze. Návrh na anglickou verzi je ve skutečnosti jeden z prvních komentářů od mého (zahraničního) kolegy.

Sám ve volném čase přispívám do překladů open source softwaru, ale pokud nebude k dispozici žádný copywriter, tak v případě zájmu z vaší strany bych se na překladu tohoto dokumentu rád podílel.

README a název dokumentu obsahují pojem veřejná sféra, kterou jsem si nejdříve vysvětlil jako soukromý sektor, soukromé firmy. Dále se ale v textu vyskytuje formulace Doporučení není pro veřejnou správu právně závazné... a ...připravena k připomínkám veřejné správy, dodavatelů software pro veřejnou správu .... Možná jsem jen neznalý pojmů, ale jaká je tedy prosím cílová skupina, pro kterou je dokument určený?

Zamýšlím se nad principem otevřeného software a požadavkem na svázání účtu ve VCS s pracovní e-mailovou adresu vývojáře...

Požadavek má několik problémů:

1. pokud je otevřený software primárně vyvíjen společností, tak daný požadavek říká, že zaměstnanci mají všichni mít účty svázány se svojí pracovní e-mailovou adresy. Jaký je k tomu důvod? Co je to "svázán"? Co na to řekne HR oddělení dané společnosti?
2. pokud do kódu přispívá nečlen primárního vývojového týmu (tedy nezaměstnanec dané společnosti), tak vyžadujeme jeho pracovní mail. Proč, když se ve své práci věnuje něčemu úplně jinému? Proč, když se softwaru věnuje ve svém volném čase? Vylučujeme tím, že by se mohl stát merge-masterem? Proč?
3. spousta lidí používá jednu e-mailovou adresu jak pro práci tak pro soukromé věci. Co je to v takovém případě pracovní adresa?
4. Trošku Venezuely (to je už spíše vtip): vylučujeme tedy nezaměstnané a důchodce?

Požadavek na pracovní e-mailové adresy tedy podle mého názoru nedává příliš smysl a zřejmě s otevřeným softwarem vlastně ani nesouvisí. Dovedu si to však představit za jistých předpokladů jako podmínku používání VCS uvnitř společnosti pro jakýkoli software (nejen otevřený).

Až teď mi došlo, že by si tento dokument zasloužil aplikovat sám na sebe (byť nejde o software), což znamená doplnit např. soubor CONTRIBUTING a hlavně licenci. Předpokládám, že to bude potřeba probrat interně v NÚKIBu, co to obnáší, ale osobně bych doporučoval Creative Commons.

S výběrem případně pomohou:

• https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-license-to-a-repository
• https://choosealicense.com/
• a přidat ji pak můžete rovnou výběrem na tomto odkazu https://github.com/NUKIB/bezpecnostni-doporuceni-open-source/community/license/new?branch=main

Jak obecná nebo naopak konkrétní má očekávaná výsledná verze tohoto dokumentu být? V #4 navrhuji doplnit informace k validaci vstupů, protože to v obecnosti pokrývá velkou třídu bezpečnostních rizik. Pak ale existují další velmi populární útoky a zneužívané bezpečnostní chyby, na které by stálo za to upozornit, ať už co se výsledného softwaru týče, nebo procesu a infrastruktury pro jeho vývoj.

Pokud by měla doporučení zůstat obecnější v zájmu stručnosti dokumentu, navrhoval bych alespoň zmínit nutnost dodržovat při vývoji opatření proti zavedení chyb z OWASP Top 10.

Nevím přesně jestli to sem patří, ale pokud to bude vyvíjet i veřejná správa, tak asi ano. Je nutné v dokumentaci deklarovat, kdo je vlastníkem toho produktu, což veřejná správa potřebuje vzhledem k zadávání veřejných zakázek, i kdyby faktickým dodavatele byl někdo jiný.

V O.5 a D.3 je zmiňován termín 30 dnů pro opravu bezpečnostních chyb. V O.3 je pak (sice jako příklad) 48 hodin pro odpověď na hlášení bezpečnostních chyb. Souhlasím s tím, že v případě bezpečnostních problémů je potřeba jednat rychle, ale nejsem si jistý, jestli je vhodně zde uvádět konkrétní termíny (nebo jsou dané vyhláškou?). Očekával bych spíše, aby vůbec nějaký postup pro řešení takových hlášení existoval a v rámci něj abych byl jako případný autor hlášení vhodně informován o průběhu a očekávaném termínu řešení, v závislosti na závažnosti nahlášené chyby. Podle konkrétní aplikace, způsobu jejího provozu a používání, a samozřejmě v závislosti na konkrétní chybě, může být 30 dnů nebezpečně dlouhá doba, nebo naopak zbytečně krutý požadavek.

Nesouvisí to přímo z bezpečnostní vývoje, ale aby projekt reálně spadal do kategorie open source, stálo by za to zmínit, pod jakou licencí musí být jeho kód dostupný. Případně existuje už k tomu ve státní správě nějaká jiné metodika nebo doporučení?

Doporučil bych v dokumentu explicitně jako doporučení zmínit ošetřování uživatelských vstupů, a to z pohledu:

• délku vstupů jako ochranu proti případným DoS a proti ztrátě dat nebo nečekaným výjimkám při ukládání do databáze z důvodu porušení typů apod.
• ochrany proti útokům typu injection (SQL injection, XSS nebo jakékoliv jiné code injection)

Rád bych otevřel téma využití decentralizovaných technologií.

Myslím, že software, který se bude používat ve státech by měl co nejvíce využívat decentralizované technologie. Nejedná se jen o známější blockchain, ale například i o IPFS (Inter Planetary File System). Tyto technologie umožní snížit náklady na vývoj, údržbu, řeší identity management, zásadně zjednodušují backup souborů, jehich přenos mezi vzdělávací sférou a průmyslem a také mají přirozenou ochranu proti ransomware (takto by se dalo ještě pokračovat dále. Detailnější analýzu zpracovalo například MPO:

MPO - Potenciál decentralizovaných technologií pro rozvoj České ekonomiky

Velkou výhodou je, že se lidé mohou zapojit do zálohování dat, držení sítě, hlasování, apod., což ochrání tato data proti případným útokům, haváriím jinak centralizovaných datových center, apod.

Z pohledu bezpečnosti hraje roli i snížení energetické náročnosti provozu státní IT infrastruktury. Díky úsporám na vývoji i provozu získáme rezervu, kterou můžeme směřovat kam bude potřeba.

Protože se delší dobu zabývám tématem digitalizace, tak jsem začal pro tyto účely psát již před rokem OpenSource Framework (https://veframework.com/). V tomto roce ho budeme posunovat výrazně kupředu a lze do něj zapracovat spoustu nástrojů, které nám zjednodušší implementaci nových systémů. Vše je free i pro komerční účely. Nyní jsem najmul několik vývojářů, kteří pomůžou s refaktoringem, zvýšením bezpečnosti a stability, dokumentací, apod. a další se budou přidávat v průběhu roku.
Již jsem koukal, že například dokládání identity, či ověřování buildů aplikací může být velmi jednoduše řešno pomocí NFT a IPFS. Máme na to už konkrétní případy (řeším to veframeworku kvůli některým security issues, které jsou v průmyslu, apod.). Postupně zkusím doplnit jednotlivé příklady, kde se co dá použít. Budu rád, když by někdo s tímto pomohl.

Přístup k technologiím skrze VEFramework lze řešit i přes API, takže i pokud je nějaká aplikace napsaná v jiném jazyce, tak může touto formou získávat data například z různých blockchanů nebo je tam posílat (nemusí přitom psát sami logiku pro podepisování transakcí, apod.). S tím souvisí i další Issue, kterou bychom měli otevřít a to je formát pro API a IoT konektivitu, ale tu otevřu samostatně.

Bezpečná aplikace by v ideálním případě neměla mít výchozí přihlašovací údaje (nedejbože statické - stejné pro každou instalaci). Případné přístupové údaje by si měl provozovatel/uživatel nastavit během nasazení aplikace/založení účtu.

Pokud už je potřeba výchozí údaje vygenerovat, mělo by to proběhnou kryptograficky bezpečným způsobem. To už je tedy popsáno v C.8.

Dobrý den.

Náš spolek OpenAlt z.s. aktivně propaguje otevřené technologie, softwarové i hardwarové, jejich používání, vývoj a samozřejmě osvětu v této oblasti. Neunikla nám proto vaše společná iniciativa vytvořit Bezpečnostní doporučení pro vývoj otevřeného softwaru ve veřejné správě.

Kromě samotného faktu, že takový dokument vůbec vzniká, velmi oceňujeme jeho zveřejnění a možnost zasílání připomínek formou komentářů (issues) i konkrétních návrhů na změny (pull requesty). Doporučení jsou formulována do poměrně jednoduché příručky, nejsou navázána na konkrétní zákonné požadavky nebo paragrafy, ale jsou použitelná obecně. Na tvorbě a doplnění dokumentu se tedy mohou podílet členové našeho spolku i další profesionálové z oboru, jak je přímo vidět z aktivity v repozitáři, takže dokument nejen open source podporuje, ale sám se jeho principy snaží řídit.

Tímto dopisem děkujeme za váš přístup a vyjadřujeme podporu při tvorbě dalších podobných dokumentů nyní i v budoucnu. Rovněž vás zveme na další ročník naší konference OpenAlt (dříve pod názvem LinuxAlt), kterou od roku 2006 pořádáme, a kde je i vždy silné zastoupení přednášek zaměřených na téma bezpečnosti. Uvítáme vás na ní ať už jako partnery, přednášející i návštěvníky.

S pozdravem za spolek OpenAlt z.s.
Michal Stanke, předseda

Měli bychom definovat, že aplikace by měli poskytovat popis API v OpenAPI formátu. Ideálně i vč. Swagger testing UI, apod.

Stejně tak by se měla definovat konektivita na MQTT či podobné IoT protokoly. Budou je potřebovat v rámci digitalizace všechny aplikace.

Co myslíte?