O metodike Red Flags

v NKIVS alebo niecom podobnom nie je takyto princip definovany? Lebo s uradnikmi v SR pohne len dokument/pokyn zo SR a nie manual z UK

1 Like

…este by bolo dobre mat moznost zadefinovat, kto sa realne podielal na realizacii projektu…ktore firmy boli, ci uz priznani alebo nepriznani subdodavatelia…ciel je odclenit zrno od pliev a hladat korelacie medzi lepsi projektami a subjektami, ktore ich dodavali a potom sa pytat, ze preco taketo firmy nedostavaju prilezitosti byt priamymi dodavatelmi/clenmi konzorcii…

2 Likes

Zdravím,
niekoľko vecí, lebo zrejme sa jedná o starší dokument (koncept) a neviem nakoľko autor prešiel na novú terminológiu

  • terminologia (treba zosúladiť s aktuálnym stavom, nie sú napr. eGOV služby ale KS, AS, IS… a pod), v rámci štúdie nie je predmet štúdie, sú tam iné kapitoly,

Teraz trošku ku metodike písania toho modelu:

  • Celkove tie body idú tak hore-dole, možno by bolo dobré metodiky pre každú oblasť napísať, alebo z akých metodík sa vychádza pri posudzovaní tej ktorej oblasti (aby bol jasný aj prijímateľovi čo má splniť, aby bol ready) - v podstate každá s tých vecí vychádza z nejakých legislatív asi štandardov, zahraničie a pod…
  • fázy projektu sú v zmysle PRINCE alebo Výnosu - inicializačná, prípravná… atď ak chcete riešiť iné členenie, potom OK ale treba asi napísať ako postupovať a ako tú etapu identifikovať v projekte (lebo ju nemusí mať :slight_smile:
  • pre každé hodnotenie by sa mal stanoviť cieľ (napr. produkt, aktivita a pod) a kritériá kvality pre každý ciel alebo to čo hodnotníme
  • všetky ciele by mali mať jasnú hierarchiu, t.j. aby relevantné kritériá a ciele na seba nadväzovali
  • chýbajú stanovené tolerancie, t.j. kedy je to už stop a kedy ešte ready (t.j. čo ak, čo potom?) čo tak korekcie a opravné postupy …

ku konkrétnym veciam asi, ked to bude konzistentnejšie :slight_smile:

2 Likes

V rámci projektu Red Flags pripravujeme workshopy v Žiline, Košiciach a Bratislave. Predbežné eventy (na save the date) tu:

Žilina
Košice
Bratislava

Čoskoro doplníme aj podrobnosti ohľadom obsahu a presnejšieho miesta aktivity v daných mestách. Akékoľvek nápady, čo by na nich nemalo chýbať, vítame. Pridajte sa prosím na tieto eventy, prípadne o nich povedzte kamošom, ktorých by to zaujímalo.

1 Like

A post was merged into an existing topic: O kategórii Red Flags

Mame novinku! Ako sa da zapojit do hodnotenia red flags

Ahojte, pozeral som si teraz draft s kritériami.
Veľmi som zvedavý, na diskusiu v časti realizácia. Sú tam kritériá projektová dokumentácia, harmonogram projektu, analytická dokumentácia … a potom samozrejme agile :). Pričom niektoré z týchto vecí sa ťažko zosúlaďujú, často idú proti sebe (agile chce len minimum dokumentácie, tu sú jej venované aspoň dve kritériá a pôsobia mierne vodopádovo; harmonogram/miľníky/kontroly/plnenie opäť ťažšie uchopiteľné v agile prístupe). Nevravím, že zle a že sa nedá, len že som zvedavý, ako sa podarí tieto komplikované, protichodné a užitočné veci skĺbiť. Teším sa na tú diskusiu. Možno by nebolo zlé osloviť aj slovenskú agile komunitu a pokúsiť sa ju zapojiť (podobne ako napr. UX) aj do riešenia slovenského eGov.

2 Likes

zdravim vsetkych, mne v hodnoteni redflags chyba hodnotenie bezpecnostnych aspektov projektov. ci uz v zadani projektu (napr. poziadavky z legislativy a pod), alebo potom aj v ramci projektu (napr. rizikova analyza, vyhodnotenie bezp. dopadov na ine systemy a pod) plus urcite este niekolko dalsich veci. nepremysla sa nad niecim takym?

To je dobrá otázka. Našim cieľom nie je totiž pokryť “všetko” čo sa projektov týka, ale špeciálne veci ktoré sú rizikové, v čom doterajšie projekty mali zlé/slabé výsledky, alebo čo môže indikovať problém do budúcnosti.
Aké teda boli “red flags” v bezpečnosti doterajších projektov?

Neexistencia poziadavky na spracovanie bezpecnostneho projektu v zadani, nedefinovanie bezpecnostnych poziadaviek v zadani, neuvadzanie legislativnych predpisov suvisiacich s infosec v zadani, ktore maju dopad na predmet projektu , napriklad :slight_smile:

Daj prosím konkrétny príklad kde to takto bolo a viedlo to k zlému výsledku, nejako si neviem spomenúť (a zvonka to nevidno).

Myslim ze priklady uvadzat netreba. :slight_smile: ty aj ja dobre vieme, ze ked sa v projektoch nezadefinuju bezpecnostne poziadavky, vznika big security problem. A este som zabudol na chybajuce bezpecnostne testy…

IvanK to dobre zhrnul. podla mna bezpecnost nieje “vsetko”. netreba ist hlboko, ale imho by mal existovat jeden - dva redflagy, ktore by ukazovali, ako vyrazne v projekte na bezpecnost mysleli. Podstatna by asi bola existencia niecoho ako rizikovka, aby bolo jasne co treba v projekte pokryt. A existuje cast projektov s vyraznym bezpecnostnym aspektom - u tych by mohli byt dalsie dodatocne redflags.
Ako priklad mozes brat hoci aj aktualnu kauzu eID - je evidentne, ze ani v takto dolezitom a bezpecnostne citlivom projekte nebolo myslene na incident response, alebo IR plan nieje dodrziavany. aspon to tak zvonka vyzera.
Robim bezpecnost aj v statnych projektoch a nepamatam, ze by boli niekde v zadani projektu realne pouzitelne security poziadavky.
Bezp. testy sa uz aspon vo forme externych blackbox pentestov musia robit (csirt), ale nic viac pokial viem nieje.

Najvacsi problem s bezpecnostou v statnej sprave je implementacia procesnych opatreni. Aj ked dodavel nachysta policy, postupy, procedury usije to na mieru potrebam konkretneho ministerstva, tak nema to kto robit. Vsetci maju zufaly personalny podstav, za tie ich prachy nikto kvalifikovaneho bezpecaka robit nepojde. Iste, toto nema s redflags projektu nic spolocne. Ale treba si to uvedomit. Mozno cesta vedie cez specializovane SLA na security. MSS. Ked sa schvali kybersec zakon, budu musiet vybudovat vpa-cky. Som fakt zvedavy kto to zvladne.

Len malu poznamku. Ak mas ludi, rozpocet a volu agile nemusi ist proti poziadavkam na dokumentaciu. Len si treba uvedomit, ze sa vodopadovo na dokuemntaciu necaka. Veci sa dohodnu na workshope/telcu… a vyvojar ich hned implementuje a analytik paralelne zakresluje, popisuje. castokrat je softverova cast skor ako UML/dolkumentacna. ak vsak najdes dobru techniku (toolbox a postupy) ako tu analyzu vyuzit na tvorbu priruciek, helpov, skoliacich materialov … tak si vyhral … inak bude dokuentacia furt pozadu … avsak je si treba uvedomit ze RELEASE bez dokumentacie neodovzdas (pokial nefejkujes). Takze v sprinte musi byt vzdy aj cas na dokumentaciu ak teda chcem dodrzat pravidlo ze na konci sprintu musi byt chodivy a odovzdatelny release.

No mozno by som navrhol další approach. Tak ako sa daju flagovat vyvíjané, alebo zamýšľané projekty, tak sa dá flagovať aj prevádzka (alebo pred realizáciou, zamýšľaný spôsob prevádzky). To znamená, kde to bude nainštalované, ako je to tam so stavom administrátorov a prevádzkových manažérov, ako tam majú riešenú bezpečnosť všeobecne a ako do toho zasiahne nový zamýšľaný projekt. Ako vyzerajú postupy v danom datacentre. Čo sa deje pri malom výpadku, čo sa deje pri kritikom výpadku, vedia vôbec ľudia ohodnotiť dopady výpadkov ? Aká je fyzická možnosť dodávateľov rýchlo niečo diagnostikovať, majú tam vôbec prístup (fyzický / vzdialený) ? Ak mú v kritickej infrastruktúre zapojené jedinečné HW zariadenia, je zabezpečený ich support (výmena) v prípade výpadku ?.. a podobne. A myslím, že to je (aspoň sčasti) to čo @IvanK myslel svojim príspevkom.
Pretože ako baba Vanga hovorí napríklad celý eHealth padne najskor práve na toto …

(bezp. projekt nadefinoval učitý počet rolí, ktoré sa nesmú prekrývať jedným človekom … a ak chcem zabezpečiť 24x7x365, tak tam musíš mať 3 smennú prevádzku s premysleným zastupovaním. Na nielktoré tie role ani tolko certifikovaných ludí čo by ten eHealth potrebival nenájdeš… A reálny stav je pár ľudí v jednosmennej prevádzke, v režime permanentnej nespokojnosti … Takže čo sa celé tie roky robilo ?)

PS: je mi jasné že dostať sa k týmto informáciám nie je jednoduché, lebo prevádzka datacentier môže a možno by aj mala byť v sprísnenom až utajovanom režime. Ale možno sa podarí také niečo vnúknuť do hlavy Pellému a on už veci zariadí z pozície sily :slight_smile: . Vo vlastnom záujme.

1 Like

Ano v tomto mas absolutnu pravdu. Tak to je az na svetle vynimky vsade v statnom sektore. a vidim uz aj priklon k SLA … aj k specializovanym security. Ale stale iba viacmenej o prevadzke bezpecnosti (udrzanie pri zivote, updaty, aby vsetko prispievalo do SIEM, pripadne nejaky rychly check manazmentov/SIEM raz za tyzden/dva). Bezpecnostna SLA v zmysle kontinualneho monitoringu, analytiky, incident response a pod je zatial iba vo hviezdach.
Edit: mozno by stalo za myslienku nieco ako jednotne SOC pre stat, aspon pre male projekty, ktore nemaju vlastne kapacity na udrziavanie bezpecnosti. Ale to je zatial asi iba moja fantazia …
Edit2: btw prave (aj) taketo situacie by mala rizikovka pokryvat a malo by z nej byt jasne, ake su rizika, ako sa daju pokryt a co sa stane ak nebudu pokryte. To je prvy krok. Druhy je navhnutie procesov/technologii/postupov a pod na ich pokrytie. A treti krok je realna realizacia navrhov, teda aj zvysenie personalneho stavu ak to projekt vyzaduje…

Prevadzka sa da flagovat iba do urovne, ktora je spomenuta v projekte. A casto tam o tom nic podstatne nieje. Stav adminov moze dopadnut tak, ze v ramci projektu sa rata s navysenim poctu adminov kvoli jeho prevadzke a nakoniec niekto prepusti aj polovicu aktualnych adminov, lebo setrenie. IR sa tam pokial mi pamat siaha nikde nespomina, pokial to nepotlaci poctivy dodavatel. Ostatne detaily casto niesu zname ani zadavatelom a dlho ani dodavatelovi.
Taketo hodnotenie ako hovoris by mala riesit v ramci statu niektora z organizacii (ja som bol vzdy za nieco ako ministerstvo informatizacie alebo nejaky prierezovy utvar s velkou vahou … a aj politickym pokrytim, aby mohol aj na ministra) interne, pre kazde ministerstvo, organizaciu, a projekt. Akesi ich interne redflags. Aby sa zamedzili duplicity (obrovske), zabezpecila koordinacia jednotlivych projektov, ich integracia medzi rezortmi a podobne. Proste aby to malo pana. Samotne ministerstva na to nemaju personalne ani odborne.
Co sa tyka eHealth, tak tam sa napr. robila rizikovka a security je tam ponata dost komplexne. POcet roli vypadol prave z toho. Je to dost dolezity projekt, aby sa koli nemu viedla aj 3smenna prevadzka a prijalo sa par adminov. A nemusia sediet prave v BA, kde je vysoka fluktuacia a ludia sa tam tocia ako kolotoc. A ked sa pytas, co sa za tie roky robilo? Ubudalo adminov :slight_smile: Aktualne su tam na sec infra dvaja.

Rozumiem. Poriadne riešenie bezpečnosti je samozrejme dôležité. Aj si viem zhruba predstaviť čo by sa dalo v časti “produkt” takéhoto projektu vyžadovať/kontrolovať. Akurát že tieto veci nikdy nebudú pre nás (verejne) dostupné. Čo s tým?

Jakze nie? V podkladoch k obstaravaniu predsa vidis ci je pozadovane napr. to co som pisal vyssie.