V ramci skupiny K9.8 Kybernetická bezpečnosť by sme sa chceli za Slovensko.Digital venovat nizsie uvedenym temam ktore suvisia s NKIVS SR 2016.
1. Ulahcit a sprehladnit dokumentovanie aspektov kyberbezpecnosti v ramci projektov tykajucich sa ISVS:
napad je, ze by sa vytvoril wizard/sprievodca/kucharka (napr aj ako webova appka), ktory sa pomoze zorientovat projektovemu timu co musia zdokumentovat v danej etape (faze projektu), na co nezabudnut. Tj na zaklade aktualneho kontextu, by sa im vygenerovala prislusna sablona (casti) specifickeho dokumentu (napr DFS, Prevadzkove prirucky, SLA,prip aj DIZ, SU,…), existujuce sablony sa zohladnia), teda hlavne kostry kapitol tykajucich sa kyberbezpecnosti s popismi a prikladmi ako ju vyplnit a v akej miere detailu. Ale samotny obsah uz musi vyplnit projektovy tim.
Aktualny kontext by bol tvoreny sadou parametrov(ktore by sa vyklikali vo wizarde) ako napr: v akej faze zivotneho cyklu riesenia sa nachadzam (bud podla TOGAF ADM faz [preliminary, vizia, biznis architektura, aplikacna arch., technicka arch.,…], alebo podla fazy SDLC [analyza,dizajn,implementacia/integracia,testovanie,.], alebo podla ITIL pohladu [incident manazment, change manazment, deployment, service level manazment, availability management,…]; dalej aky velky rozsah ma moj projekt (vystupy budu rozdielne pokial sa jedna o malu oganizaciu s minimalnym IT prostredim, ktora chce budovat maly system, a ine pokial sa bude jednat o novy komplexny ISVS pre velku organizaciu integrovany na mnozstvo inych systemov,…); a dalsie explicitne obmedzenia.
Vystupom by bolo: zoznam relevantnych dokumentov ktore je treba vyplnit, odporucania aky pozadovany obsah a kapitoly treba vyplnit (tie by sa aj predgenerovali), aka uroven detailu musi byt zohladnena, a ake relevantne referencne zdroje sa odporucaju pouzit (napr standardy ISVS, konkretne paragrafy, zakon o ochrane os. udajov, GDPR, metodiky/usmernenia, csirt dokumenty, Integracne manualy ISVS, OWASP standardy,…). Uvedene kapitoly by sa dali zaintegrovat do uz existujucich dokumentov ak ich organizacia uz ma. Tu by este stalo za uvahu vybudovat standardny katalog zranitelnoti a rizik - centralne manazovany pre verejnu spravu.
Myslime si, ze taketo nieco by v praxi pomohlo (zorientovat sa v spleti legislativnych a inych dokumentov/pravidiel).
2. Inovácia štandardov a riešení v oblasti identifikácie, autentifikácie, autorizácie a vytvárania záznamov:
Autentifikacia:
povysit modul autentifikacie (UPVS IAM) do pozicie identity brokera, tj platformy, ktora by sprostredkovavala prepojenie viacero IDPs(Identity Providerov) s roznymi SP(Service Providermi), s roznymi autentifikacnymi prostriedkami roznej urovne assurance, a s rozsirenim aj na komercny svet (tj nielen v ramci ISVS/GOVNET prostredia). Aktualne UPVS IAM poskytuje jediné IDP s RFO ako user repozitory, a s eID kartou ako auth. prostriedkom (a GRID karty pre niektore typy identit). Cielom by malo byt zapojenie viacerych IDP(napr banky, telco, socialne siete,…, ktory musia splnit urcite standardy, tj prejdu certifikaciou na danu uroven assurance - vid napr GOV.UK Verify. Tieto identity z certifikovanych IDP by boli vzdy nalinkovane na hlavnu identitu z RFO(ktoru ma aktualne UPVS IAM). Cize “statne” ISVS by mohli akceptovat prihlasovanie cez komercne IDP, a naopak, komercne systemy by mohli akceptovat statne IDP/prihlasovanie.
- rozsirit protokol federacie identit o oauth2 / OpenID Connect, pripadne aj ine,…
- autentifikacia (a aj autorizacia) cez Mobilne Platformy, tj zaviest standardne riesenie plosne podporovane pre vsetkych, staci s Levelom 3 (tj sw riesenim; pre level 4 je vyzadovany hw token) - vid diskusiu ÚPVII Pracovná skupina K9.5 Lepšie služby
Autorizacia:
- vytvorit nizsi level autorizacie (aktualne je len level ZEP, resp nic) ekvivalent obycajnemu vlastnorucnemu podpisu (bez overenia notara…) s plosne dostupnou implementaciou , nas navrh je obycajne kliknutie ak som prihlaseny min. levelom 3 (tj aj z mobilu), toto bude explicitne logovane, kvoli fraud detection.
3. Riesenie ochrany osobných údajov a riadenia prístupu k údajom, založene na princípe ‘laissez-faire’:
pri g2g zdielani udajov (tj medzi ISVS) sa aktualne podpisuju papierove zmluvy o spristupneni udajov v danom rozsahu a pre dany ucel (napr ministerstvo ma ISVS, ktory chce udaje z RFO,…), napriek tomu ze obe statne institucie su v TRUSTED - GOVNET prostredi. Toto sa nam zda ako komplikovane, a skor sa nam zda lepsi flexibilny mechanizmus (ktoreho koncept je uz rieseny v skupine K9.4 Lepsie Data) - modul riadenia pristupov k udajom, tj jednalo by sa o centralny ACL, kde by bolo evidovane, ktory zdrojovy subjekt pre svoju agendu (ciselnik agiend by mohol byt z MetaIS) ma opravnenie na ktory cielovy subjekt a ktoru agendu, a na ktory typ datoveho objektu. Vsetky pristupy k udajom budu detailne logovane, tj da sa vyhodnotit pokus o fraud.
4. Zavedenie (bezpecnostnych) limitov pre egov transakcie (podania):
zaviest mechanizmus podobny ako maju banky, ze max limit transakcie za den je XXX eur, resp danym autentifikacnym prostriedkom mozem previest len sumu do XXX aur,…, tj aby si mohol clovek zvolit ake transakcie(egov/koncove sluzby chce elektronicky vykonavat vo svojom mene, a ake nechce (resp chce na to dodatocny osobny suhlas/pritomnost) - napr sluzba predaja nehnutelnosti, zmena trvaleho pobytu, atd, tj sluzby, ktore su z urciteho pohladu “kriticke” (tj aby ich niekto nezneuzil/nehackol v mojom mene)
- s tymto uzko suvisi fraud detection podvodnych podani - bolo by dobre definovat standardne API, pre toho, kto by chcel poskytovat svoje specificke fraud detection algoritmy (napr komercne firmy, banky,…), ktore by sa spustali v ramci orchestracie elektronickych podani
–
Aky je Vas nazor na uvedene namety?, co by ste chceli na nich vylepsit? mozme ich spolocne rozdiskutovat, resp pridat dalsie…