https://jaroslavkmet1.blog.sme.sk/c/507604/da-sa-u-nas-usetrit-v-statnom-it.html
dobre tomu rozumiem ze konecne sa dohadali a stat dostane vsetky zdrojove kody ku produktom ktore budu pren vytvorene?
pamatam si este na itape poslednej kde jano hargas diskutoval ze dodavatelia boli zasadne proti tomu
Zmenilo sa to, že je prijatý Zákon o ITVS, v ktorom je požiadavka dodávať všetok kód vytvorený na objednávku pod EUPL “a to v rozsahu, v akom zverejnenie tohto kódu nemôže byť zneužité na činnosť smerujúcu k narušeniu alebo k zničeniu informačného systému verejnej správy”.
Dodávatelia svoj pohľad nezmenili, takže očakávam pokračovanie hádania sa práve o tú bezpečácku výnimku.
Specialne na tuto cast som velmi zvedavy, mozno by mohol niekto s CSIRT prezradit ako si to predstavuju. Zmurk @Lukas_Hlavicka.
Hodi sa k tomu tento odkaz: Proof of impossibility - Wikipedia
Predstava za CSIRT bola taka, ze primarne sa to bude tykat bezpecnostnych opatreni (logovania, kontroly vstupov a podobne) a kritickych operacii (napriklad overovanie a podpisovanie dat). Za CSIRT moze vsetko ostatne ist po kontrole von.
Ale samozrejme analyzu rizik tychto systemov ako celku nerobi CSIRT, ale ine prislusne utvary na urade.
1 Like
Skusme toto trochu rozmenit na drobne, ze ci to chapem spravne. Povedzme, ze mame standardny agendovy system + nejaku elektronicku sluzbu smerom k obcanom/podnikatelom.
- logovanie - na akej urovni? Povedzme, ze pred API je postaveny nejaky centralny API GW. Ten loguje, vselico kontroluje, rate limitu. Znamena to, ze vsetko ostatne moze byt zverejnene? Ked to prezeniem, nestaci pred to postavit nejaky jeden bezpecnostny layer, ktory oreze kadejake pokusy botov/utokov?
- kontrola vstupov - validacie formularov su kontrola vstupov? Kde tu je riziko?
- overovanie a podpisovanie dat - hmm, zvlastne, ze prave tieto kniznice SSL… su naopak vo svete uplne opensource, aby bol obrovsky tlak na ich kvalitu a bezpecnost. Nebude mat zavretie tejto casti opacny efekt? Mimochodom, tento pohlad malo aj UK a nakonieco uplne zverejnili kod prave casti autentifikacie. Opening the GOV.UK Verify Hub source code - Technology in government
Samozrejme sa nepytam na oficialne stanovisko (aj ked by bodlo), ale skor predstavu, ze kde bude manervovaci priestor na “kreativne vyklady”.
1 Like
Zdravim, dobre otazky, skusim teda spomenut zopar prikladov a vyjadrit moj nazor na konkretne pripady.
Edit: ospraveldnujem sa za dlzku prispevku, rozpisal som sa viac, nez som cakal.
nepovedal by som to uplne jednoznacne tak, ze vsetko ostatne okrem logovania v API GW. Zalezi od konkretneho pripadu, ale viem si predstavit aj IS, ktore su navrhnute tak, ze okrem centralneho API GW pre integrovane sluzby maju aj vlastny frontend a aplikacnu vrstvu, ktora moze narabat s databazou napriamo bez vyuzivania na to urcenych API (rozumnost takehoto riesenia je na inu diskusiu, no aj toto sa da obcas najst…). A aj pri takomto narabani s databazou mozu programatori doplnit logovanie (ved ked maju poziadavku, ze kazda akcia nejakeho typu ma byt logovana, tak preco nie?). Teda nebral by som to tak, ze ak sa v navrhu IS vyskytuje centralny API GW, tak ten sa nezverejni a zvysok ano. Okrem toho, kontrola, kde vsade je logovanie, moze prinutit zamysliet sa nad navrhom IS este v pociatkoch a pripadne ho vylepsit.
takyto bezpecnostny layer je pre mnohe IS odporucany, v pripade webovych aplikacii napr vo forme WAF (web application firewall). Dobre nakonfigurovany WAF zvladne odfiltrovat standardne utoky, no je taktiez odporucana aj kontrola uzivatelskych vstupov na strane aplikacie. Nieco na sposob multivendor ochrany. Ak by WAF nepokryval nejaky utok, tak to prelezie az ku webovej aplikacii a ak to neodfiltruje ani ona, tak utocnik bude uspesny.
Validacia v zmysle kontrola specialych znakov ci povolenych znakov vo vstupe, specifickeho formatu a typu sa povazuje za kontrolu vstupov. Riziko je napr v pripade webovych aplikacii moznost prepasovania specialnych znakov vo vstupe, ktory je dalej spracovavany a nejakym sposobom interaguje s databazou alebo sa zobrazuje na stranke. V prvom pripade to moze viest ku SQL injection, v druhom napr ku XSS. Moze sa to dat zneuzit aj sposobmi, ktore nie su uplne na prvy pohlad zrejme, napr v pripade C/C++ aplikacie, pokial sa niekde objavi prikaz printf(s), kde s je vstup zadany pouzivatelom, toto sa moze dat zneuzit na exploitaciu a spustenie kodu podvrhnuteho utocnikom.
Vo svete ano, pri siroko pouzivanych opensource knizniciach (napr OpenSSL, LibreSSL) sa na ich kvalitu a bezpecnost pozera aj mnozstvo vyskumnikov, programatorov a bezpecakov, ktori ked najdu chybu, nahlasia ju. Z mojho pohladu je Slovensko v tomto specificky trh, ak by sa zverejnila cast ohladom podpisovania a overovania dat v nejakom menej znamom IS, kolko ludi sa na to len tak pozrie vo svojom volnom case a trebars spravia aspon ciastocny audit? Kolko z tych ludi, co by to na Slovensku dokazali, tak maju prehlad o ISVS, v ktorych sa vyskytuje aj takato funkcionalita? Ak sa chceme branit, museli by sme takto pokryt a skontrolovat vsetky systemy, na druhej strane, utocnikovi sa staci zamerat na jeden system a ten skumat dovtedy, kym nenajde jednu zranitelnost. Navyse, chyby v kryptoknizniciach mozu byt lahko prehliadnutelne (je potrebne nielen vediet programovat a auditovat kod, ale aj rozumiet kryptografii). Mimochodom, jeden priklad pomerne zjavnej chyby, ktora sa vyskytla v Apple implementacii SSL/TLS a umoznovala obist overovanie:
…
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;
…
fail:
SSLFreeBuffer(&signedHashes);
SSLFreeBuffer(&hashCtx);
return err;
Ako dlho by asi trvalo objavenie takejto chyby v slovenskych podmienkach, keby sa nieco podobne vyskytlo vo verejnosti menej znamom systeme?
Nuz, snad som zodpovedal otazky aspon pre lepsiu predstavu, kde mozu byt rizika z pohladu bezpecnosti v slovenskych podmienkach.
1 Like
Dovolím si tvrdiť, že toto “občas” je skôr “drvivá väčšina” webaplikácií na svete. Samozrejme riziká chápem.
Otázka teda znie či a kedy toto waf a iné bude mať vládny cloud / paas alebo jednoducho využijeme služby ktoré dnes giganti ako azure, Google, Amazon na toto ponúkajú. Celý svet smeruje do public cloudov, my nejako na Slovensku máme pocit, že dokážeme vládny cloud ochrániť lepšie. Asi tiež špecifický trh?
Toto už snáď dnes nikto nerobí takto na kolene, každý rozumný framework / knižnica toto musí mať vyriešené. Nehovoriac o tom, že closed source toto moc nechráni, keďže kadejaké sqli xss testovacie skripty to nájdu skôr ako keby sa mal útočník hrabať v kodoch.
Ja by som iba upozornil, že veci typu kontrola vstupov, či podpisovanie sú jednoducho naprogramovateľné správne a aj jednoducho overiteľné či fungujú správne. Ak sú napísané príliš zložito alebo neštandardne, je to riziko samo o sebe a malo by to byť prerobené.
Skutočná výzva pre overenie bezpečnosti kódu sú oveľa subtílnejšie veci. Napr. postranné kanály. Logické chyby kódu. Race conditions. A podobne. Neviem si predstaviť, že by niekto reálne robil napr. analýzu časovacích útokov (plošne).
Pri ochrane cloudu by sa dala vyuzit nova ML sluzba microsoftu Sentinel, ktoru v marci predstavili
Autonomne sluzby Oraclu to stale nie su ale je to aspon hodena rukavica k zabezpeceniu hoci aj statnych IS
AWS to vidi takto
Sry, ale povazujem za uplne nerozumne a nezmyselne davat citlive alebo dolezite veci do public cloudov, ktore nemame pod kontrolou. Treba si uvedomit, ze ako nahle raz svoje data dam niekde mimo uz to nie su moje data. Toto je zakladny princip. Zavislost na externych dodavateloch - softverovych, outsourcingovych treba minimalizovat.
Kto nam garantuje ze ten public cloud nekupia napriklad niekto kto chce nase data a ma na to dost penazi a nezoberu si rovno vsetky nase data ? 
Vopred sa ospravedlňujem za nie-politicky-korektné formulácie. Je fajn keď tu diskutujeme.
Čo tým presne myslíte?
Akože nemáme pod kontrolou? Veď je tu kilometer regulácií (spomeňme povedzme GDPR) a certifikácií.
Nie. V dnešnom svete je práve táto predstava mimo (úplne sa prieči realite).
Ja rozumiem že základ bezpečáckeho pohľadu na svet je “paranoia is good”, ale treba to mať pod kontrolou.
Doteraz nevadilo, že v množstve kritických systémov objednávateľ nemal ani prístup k zdrojovému kódu? Čiže de-facto nevedel ani zistiť, čo ten “jeho” systém vlastne robí?
Provokatívny príklad: Viac dôverujem cloud centru Amazonu, ako nášmu Ministerstvu vnútra. MVSR malo za posledné roky viaceré škandály spojené s podozreniami zneužitia právomoci a korupcie, spoločnosť Amazon Web Services EMEA SARL nie.
Zaujímavé že táto myšlienka zaznieva iba veľmi selektívne. Dnes je verejná správa na 99% závislá na externých dodávateľoch softvéru. Čo v tejto oblasti plánujete robiť?
Jedna zo základných myšlienok “cloud computingu” je, že služba je komodita - dá sa ľahko vymeniť. Pri IaaS presuniem celú VM.
Vyjadrenia o Číne ako riziku považujem od bezpečákov, ktorý napriek opakovaným požiadavkám nie sú schopní sformulovať ani oficiálne stanovisko k HW Huawei (bez ohľadu na to aké by bolo), za nehorázne pokrytectvo.
3 Likes
A kto garantuje, že toto už dávno nejaký súčasný dodávateľ nerobí? Možno aj nevedomky.
Bude vladny cloud bezpecny? Ako bude zabezpecene, aby si vnutro alebo sis nelistovali v DB skolstva, justicie, socialnych veci? Bude postaveny na autonomnych technologiach, na AI a ML? Znizia sa naklady oproti inym rieseniam napr. AWS, oracle cloud, azure?
Budu DB konecne sifroavne?
Bude vediet zabezpecit vladny cloud 99,995% pristupnost vratane planovanych odstavok?
Kto prevezme zodpovednost za bezpecnost? bezpecnost pri private cloudovych rieseniach prebera totiz dodavatel cloudu
2 Likes
Klinec po hlavicke toto (pun intended). Len mne presli tot nedavnu rukami asi 3 studie na projekty, kde sa vyhovarali na to, ze nas vladny cloud je “nebezpecny” z pohladu dat a SLA. Ano padlo slovo “non-gdpr compliant”.
Pre inspiraciu
You can store data classified up to ‘official’ on the GOV.UK PaaS.
You cannot store data classified ‘secret‘ or ‘top secret‘ on the GOV.UK PaaS.
A kdeze to je hostovany ten gov.uk paas a na com?
GOV.UK PaaS uses the open source Cloud Foundry [external link] project, and runs on Amazon Web Services.
THE HORROR!!!
Ono je to este horsie. Na nemenovanm ministerstve nemaju pod kontrolou ani IAM, ani BPMN engin Ked ako dodavatel mame doadavat nejake integracne CR, tak zhorozu zistujeme ze IAM sa deje bud priamo u dodavatela, alebo pod jeho uplnou kontrolou. Takze skutocne , este raz skutocne viac doverujem adminom z AWS, alebo AZURE, ktori v nekonecnom priestore obroivskeho datacnetra spreavuju 100000 aplikacii tisicov zakaznikov, ako tomu amaterizmu u nas. Ta bezpecacka paranoja totiz vychadza z mylnej predtsavy ze vsade sedia aklo admini ludia na urovni zdatnych etickychg hackerov. Ale UUUUplny opak je pravdou, a dnesne statne systemy su celkom mimo kontroly statu.
1 Like
ajajaj … toto zdrzalo NCZI o cele roky …
1 Like
Ono vies, pokial DB nebudu sifrovane, kocnerovi a jemu podobnym bude velmi jednoduche ziskavat informacie.
Sifrovanie db je aj na ochranu pre adminov developerov, aby sa mohli sustredit na svoju pracu a nemuseli robit inu pracu.
A nelustroval to nahodou cez nejakeho cloveka co tam mal pristup? Autonomny cloud je ti v tomto na milu jarmilu.