AJPES kot najbolj transparentni državni organ javno objavil vse svoje registre

Verjetno, seveda pa tukaj moraš ločiti razliko med:
- osebo, ki je obveščala o napaki
- osebo, ki je zlorabljala napako (in dumpala podatke ter se morebiti okoriščala z njimi)

saj ni rečeno, da gre za isto osebo.

Sem si pogledal ta intervju in sem tudi jaz dobil občutek, da se ponovno išče nekdo za linčanje, nekoga, ki ne predstavlja AJPESa ali izvajalcev. Čeprav ni rečeno, da je oseba, ki je obveščala dejansko tudi dostopala do omenjenih osebnih podatkov.

Na AJPESu? Če novica drži so imeli third-party izvajalca in na AJPES pade "samo" del odgovornosti.

kuglvinkl je 13. feb 2017 ob 11:11 izjavil:

jukoz je 13. feb 2017 ob 11:09 izjavil:

Mimogrede, a je kaj informacij kaj se je zgodilo s Telemachovim primerom?

https://slo-tech.com/novice/t685525/0

Od GBX-a oz. SI_certa misliš?

Kogarkoli? AKOSa recimo. Je bil Telemach kaj obravnavan zaradi tega, ker to je resna malomarnost, ki si jo takšno podjetje ne bi smelo privoščiti.

Malo slabo poznate eni civilno pravo in bi želeli soditi kar malo (v tri dni) po svojem občutku. Odškodninsko morajo biti vse 4 postavke izpolnjene, pa še tedaj je komplicirano, ker je odgovornost lahko na več povzročiteljih. Kazensko pa tu ne vidim odgovornosti ne na AJPES ne na izvajalcu, temveč le na potencialnih kiber kriminalcih (mednje pa ne štejem tistega, ki je obvestil ta medij).

Banka je kvečjemu solidarno odgovorna (enako AJPES). Kar pa ne pomeni, da je lahko v celoti kdgovoren izvajalec (saj lahko nadalje od njega terja škodo). Seveda, odvisno, kako je stvari zastavila in, kaj je narocila.

Vendar ponavljam, da je škoda sploh nastala, nimamo nobenega dokaza in zato ni osnove za odskodninske tožbe.

Sploh pa ne vidim nobene protipravnosti v delu tega izvajalca, kar je ena od temeljnih predpostavk. Kvečjemu je ta na strani delikventa, ki bi udrl in podatke odtujil z izvršitvijo KD.

Odvisno tudi, kdaj je bilo to spletno mesto implementirano, če je bila ta ranljivost tedaj znana. To glede ranljivosti, ali so stvarne napake ali ne, je še precej pravno nedoreceno in tudi na sploh pri nas o ranljivosti ni dosti sodne prakse (če izvzamemo pregone KD, ki zadevajo izkljucno njihovo uporabo za vdore, kjer se jim v pravni argumentaciji sploh ne posveca pozornosti).

Bom se malo zloben (karma je kurba), ce ni denarja za begunce, je tudi za varnost ni. Tu ne gre toliko za odgovornost, ampak za primernost casa ze resen premislek, kaj in kako bomo nadalje varnost obravnavali sistemsko. Nekoga, ki nima denarja za 'take neumnosti,' pac ne gre kakor koli soditi. Pa tudi ustreznih sprejetih politik ni na drzavni ravni, ce smo resnicoljubni.

Mesar je 13. feb 2017 ob 19:18 izjavil:

Pozabljaš dejstvo, da je po njihovih izjavah sodeč nekdo delal "Penetration test" in verjetno posledično izdal papir, da je zadeva varna.

Pozabljaš, da 100 %-ne varnosti ni in še bolj pomembno okoliščino, da nihče 100 %-no za penetracijske preskuse in varnostne preglede ne jamči. In nič ni narobe, da je tako.

100% varnosti ni, lahko pa se vpogleda v poročilo o testu. Pa ne tisti "executive summary" del, ampak priloge, kjer piše točno kaj, kako in s katerimi metodami se je testiralo.

Razen seveda, če je to poslovna skrivnost.

Potem zadošča samo to, da se javno razglasi izvjalaca. Da se mu bomo drugi vedli izogibati.

Kot izziv, pa me zanima, če je AJPES sposoben najeti nekoga, ki bi spisal pošten povzetek, ki bi koristil celotni javnosti in v katerem se bi seciralo tehnične, organizacijske in operativne razloge, da je do tega prišlo, kakor tudi izravnalne ukrepe, da se temu v prihodnje izogne. Za vso IT srenjo v Sloveniji bi bilo to nekaj svežega, pozitivnega in v prihodnje tudi merodajnega, kako se obravnava incidente. Tudi v IT in tudi varnostne. (wink, wink, nudge, nudge, GBX).

Kaj zdaj, so podatke dumpali ali jih niso? (nekje sem zgleda zgrešil poanto?)

AndrejO je 13. feb 2017 ob 19:52 izjavil:

100% varnosti ni, lahko pa se vpogleda v poročilo o testu. Pa ne tisti "executive summary" del, ampak priloge, kjer piše točno kaj, kako in s katerimi metodami se je testiralo.

Razen seveda, če je to poslovna skrivnost.

Potem zadošča samo to, da se javno razglasi izvjalaca. Da se mu bomo drugi vedli izogibati.

Kot izziv, pa me zanima, če je AJPES sposoben najeti nekoga, ki bi spisal pošten povzetek, ki bi koristil celotni javnosti in v katerem se bi seciralo tehnične, organizacijske in operativne razloge, da je do tega prišlo, kakor tudi izravnalne ukrepe, da se temu v prihodnje izogne. Za vso IT srenjo v Sloveniji bi bilo to nekaj svežega, pozitivnega in v prihodnje tudi merodajnega, kako se obravnava incidente. Tudi v IT in tudi varnostne. (wink, wink, nudge, nudge, GBX).

Pri nas je to problem sistemske narave, pomanjkanja ustreznih politik prav za prav (pri cemer dodatnih pravnih norm ne potrebujemo). In ja, eno taksno porocilo bi bilo odlicno za nadaljnje premisleke, oz. ukrepe (dolocanja politik ger sistemskega urejanja).

krneki0001 je 13. feb 2017 ob 19:54 izjavil:

matijadmin je 13. feb 2017 ob 18:10 izjavil:

Banka je kvečjemu solidarno odgovorna (enako AJPES). Kar pa ne pomeni, da je lahko v celoti kdgovoren izvajalec (saj lahko nadalje od njega terja škodo). Seveda, odvisno, kako je stvari zastavila in, kaj je narocila.

Če banka da na vpogled celemu spletu moje zasebne podatke, številke osebnih računov, stanja na računu,..., jo bom tožil za odškodnino. In tožbo tudi dobil. Kdo je izvajalec, kdo je testiral, kdo je vdiral, pa naj potem banka sama razčisti. Mene to niti ne zanima.

In enako je pri AJPES-u. Kdo je vdiral, kdo je naredil programje, kdo ga je testiral, je problem ajpesa. Naš problem pa je da je ajpes tudi zasebne podatke postavil vidne v spletu.

Ajpes ni ne namenoma ne nenamenoma dal nicesar na vpogled. Toliko pa menda ja znate sarkazme v clanku prepoznati in razumete, kaj je ranljivost.

Lahko je opletati, iskati neke kvazi analogije ipd., pri cemer kaze, da niti ne razumes tehnicno v cem je bil problem.

matijadmin je 13. feb 2017 ob 20:43 izjavil:

Ajpes ni ne namenoma ne nenamenoma dal nicesar na vpogled. Toliko pa menda ja znate sarkazme v clanku prepoznati in razumete, kaj je ranljivost.

Lahko je opletati, iskati neke kvazi analogije ipd., pri cemer kaze, da niti ne razumes tehnicno v cem je bil problem.

Seveda je ajpes dal nenamenoma podatke v svet, ker ni dobro stestiral programja, ki mu ga je podizvajalec dobavil. In tukaj ni nič opletanja, pa če jih še tako braniš.

In seveda vem v čem je problem. Nestrokovno testiranje programske opreme zunanjega dobavitelja, nesposobnost database adminov, da bi preverili vsaj par stvari na bazi in nesposobnost adminov in tehnikov, da bi karkoli sploh naredili.
Nosijo se pa kot pavi, pa če jim rečeš, da bi se kaj o tehničnih rešitvah pogovoril, te takoj zavrnejo, češ koji K***C si pa ti, da se bomo mi sploh s tabo pogovarjal.

poweroff je 13. feb 2017 ob 21:25 izjavil:

Torej to, da so delali pen testing je seveda zelo v redu in dobra praksa.

Ravno to jih uvršča v sam vrh v javni upravi, kar zadeva varnostnih praks (žal). Ker so redki, ki so to sploh izvedli, bi jih zelo težko kdo 'obtožil,' da so ravnali premalo skrbno.

poweroff je 13. feb 2017 ob 21:25 izjavil:

Jasno je tudi, da pen testing vsega ne more odkriti. Ampak SQL injection v obliki ki je bila prisotna tukaj je po mojem osebnem mnenju taka zadeva, da bi jo pen testing moral odkriti. Če je ni odkril je več možnosti.

Glede na razpoložljiva ogrodja za penetracijske preskuse, prav gotovo. To postavi kompetence izvajalca pod vprašaj!

poweroff je 13. feb 2017 ob 21:25 izjavil:

Prva je, da se je SQLi pojavil šele sedaj. Po informacijah, ki jih imam sedaj, to ne drži, ranljivost je bila menda prisotna že dlje časa.

Druga je, da sploh niso delali pen testinga, pač pa ISO27001 compliance review.

Tretja je pa, da je bil pen testing izveden nestrokovno.

Glede na tole:
http://erar.si/placnik/16411/prejemnik/...
rahlo domnevam, da so delali zgolj ISO27001 compliance review.

Ampak kot rečeno, ne vemo. Lahko pa jim kdo pošlje ZDIJZ zahtevek...

Čisto vseeno, tudi skladnost s tem standardom pomeni, da so se zavezali izvajati penetracijske preskuse, oz. da je (hipotetično vsaj) eden že bil izveden. To potem zopet postavi pod vprašaj kompetence/integriteto presojevalca, oz. družbe, ki je potrdilo o skladnosti izdala!

SeMiNeSanja je 13. feb 2017 ob 21:53 izjavil:

Ajpes ni ne namenoma ne nenamenoma dal nicesar na vpogled. Toliko pa menda ja znate sarkazme v clanku prepoznati in razumete, kaj je ranljivost.

Že mogoče, da ni namerno - je pa malomarno!

Malomarnost pa je lahko kazniva.
Pri nas, ki smo banana republika so kazni sicer bagatelne, malo bolj proti zahodu pa zaradi take malomarnosti lahko hudo boli glava.
Ampak glede na to, da gremo proti novi regulativi, bodo tudi pri nas lahko šle kazni za malomarnosti v nebo.

Sicer nisem pravnik, ampak mislim, da dokler ni kaj 'ušlo', zadeva še ni problematična. Problem pa postane zelo resen, ko enkrat nekaj 'pobegne'.

Se pridružujem Matthaiu v mnenju, da so verjetno samo ISO27001 compliance preverjali. Ampak očitno nekaj šepa pri njihovi implementaciji ISO standarda, če niso pomislili, da bi bilo dobro spletne strani po vsakem popravku zmlinčkati skozi enega od toolov za odkrivanje SQL injection ranljivosti, predenj se jih da v produkcijo.
Drugače pa.... kaj ni ISO27001 nekako v smislu, kot če vprašaš otroke, če so bili pridni, oni ti pa veselo prikimavajo. Ob tem, da ima eden strgane hlače, drugi zapacan z Nutello do ušes, kristalna vaza v črepinjah,.......

Ene stvari so v standardu zapisane kot zahteve, druge pa kot priporočila, za izdajo potrdila o skladnosti. Pentest je zahtevan kot esencialni del ISMS. Kljub nekim manjšim 'odstopanjem' se lahko izda potrdilo, vendar s priporočili za izboljšave, kakšna očitna neskladja pa ne smejo biti ugotovljena in neizveden pentest bi po moje sodil v to zadnjo kategorijo. Vprašanje je tudi, kdo je izvajal pentest (isti kot presojo). Vprašanje, kako je bil pentest zastavljen idt. Vprašanj je mnogo, zato govoriti na pamet, da je potrdilo o skladnosti z zadevnim standardom BV, milo rečeno neumno. Zelo prezgodaj je, da bi kaj pametnega (mi na forumu) pogruntali. Bolj me skrbi, da tudi tisti, ki so za to poklicani, ne bodo naredili tega, kar je Andrej O. napisal, da bi bilo dobro (epsko: za vse nas za v bodoče).

Dejansko, če veš kaj vse imaš v bazah in veš, da so to podatki, ki se lahko zlorabijo, moraš odtujitev takih podatkov nujno preprečiti. In nesposobneži na ajpesu tega niso naredili.
Torej so odgovorni! In kakšen šef bi moral tudi službo izgubit zaradi tega.

krneki0001 je 13. feb 2017 ob 22:40 izjavil:

Dejansko, če veš kaj vse imaš v bazah in veš, da so to podatki, ki se lahko zlorabijo, moraš odtujitev takih podatkov nujno preprečiti. In nesposobneži na ajpesu tega niso naredili.
Torej so odgovorni! In kakšen šef bi moral tudi službo izgubit zaradi tega.

Kdo je odgovoren česa in, zakaj? Pravno argumentiral ali pa nam daj mir z za lase privlečenimi analogijami, sklepi po tvojih občutkih in na sploh neumnimi zaključki.

matijadmin je 13. feb 2017 ob 23:19 izjavil:

krneki0001 je 13. feb 2017 ob 22:40 izjavil:

Dejansko, če veš kaj vse imaš v bazah in veš, da so to podatki, ki se lahko zlorabijo, moraš odtujitev takih podatkov nujno preprečiti. In nesposobneži na ajpesu tega niso naredili.
Torej so odgovorni! In kakšen šef bi moral tudi službo izgubit zaradi tega.

Kdo je odgovoren česa in, zakaj? Pravno argumentiral ali pa nam daj mir z za lase privlečenimi analogijami, sklepi po tvojih občutkih in na sploh neumnimi zaključki.

Ajpes je odgovoren vsaj neodgovornega ravnanja, ker so dopustili vdor. In zato je potrebno da nekdo leti iz službe zaradi nesposobnosti.

AndrejO je 13. feb 2017 ob 23:48 izjavil:

krneki0001 je 13. feb 2017 ob 23:28 izjavil:

Ajpes je odgovoren vsaj neodgovornega ravnanja, ker so dopustili vdor. In zato je potrebno da nekdo leti iz službe zaradi nesposobnosti.

Stvar ni tako enostavna. Lahko, da so ravnali malomarno, lahko pa so ravnala z vso dolžno skrbjo, pa so jih stvari prehitele. To, da je nekdo "dopustil vdor", pa se lahko ugotavlja šele na podlagi dejanskih podatkov in ne zgolj ugibanj ter sklepanj. Pa tudi ta "dopustil vdor" ima lahko več vzrokov in veliko je takšnih, ki ne terjajo ali celo upravičujejo izredno odpoved delovnega razmerja.

Stvar je čisto enostavna. Preden daš zadeve v produkcijo, je treba vse potestirat in narediti teste. Ker so podatki "kritični" je treba še toliko testov več. Penetration test je nekaj nujnega in se ga lahko tudi večkrat naredi, če se že greš edinega v javni upravi, ki ima vse baze registrov čez. Ker če se ve, da si edini s temi bazami, si toliko bolj izpostavljen.

Kaj misliš, kako je na bankah s takimi zadevami? zunanji dobavitelj da programje, ki se potem testira par mesecev in se podpišejo vsi sprejemni testi. Točno se ve kaj je kdo stestiral in kdo je odgovoren za nekaj kar bi moral stestirat, pa ni, če se pojavi napaka. In testi ter testni podatki so določeni pripravljeni že ob pisanju specifikacij kaj naj zunanji sploh naredi.

Recimo, ko pride nov mainframe v IT banke, je 6 mesecev priklopljen kot paralelna mašina obstoječemu in se samo testira na njem, da slučajno ne bo kake napake.

Oprosti, ampak ajpes so šalabajzarji.

krneki0001 je 13. feb 2017 ob 23:57 izjavil:

Oprosti, ampak ajpes so šalabajzarji.

Težke besede. Ampak to "šalabajzerstvo" je potrebno argumentirati, ne samo razpredati o temu, kaj vse naredijo banke, da jim oprostiš "šalabajzerstvo", potem ko še vedno zajebejo po celi črti.

SeMiNeSanja je 14. feb 2017 ob 00:16 izjavil:

AndrejO je 13. feb 2017 ob 23:48 izjavil:

Vse se torej začne pri ugotovitvi dejanskega stanja in transparentnosti glede izsledkov. Glede na potencialen obseg incidenta, mislim, da je do tega upravičena vsa zainteresirana javnost in ne samo tista, ki želi biti prednostno obveščena. Zdaj ... lepo bi bilo, če se takšno stvar naredi zlepa in kot primer dobre prakse. Ampak, če pa to ne bo šlo tako, in glede na to, da je AJPES pravna oseba javnega prava, pa se lahko to doseže tudi malo bolj zgrda in z uporabo kakšnega ZDIJZ.

Se strinjam, da bi bilo lepo - ampak treba je biti tudi realist. Tako izčrpno poročilo o tem, kaj je šlo narobe in kaj so se naučili na svojih napakah, zahteva nekaj dela. Ne dvomim, da bo to delo takointako opravljeno, vendar je treba takšno poročilo redaktirati - niso vsi podatki primerni za javno objavo.

Morebitna redakcija takšnega poročila zahteva minimalno dodatnega napora. Osnovno delo pa mora biti opravljeno v vsakem primeru, če naj bo govora o dobro opravljenem delu.

SeMiNeSanja je 14. feb 2017 ob 00:16 izjavil:

Lepo bi tudi bilo, če bi npr. SI-Cert pri vsakem primeru, katerega obravnavajo, 'stranko' vprašali, če smejo objaviti (anonimizirane) podrobnosti o incidentu. Marsikdo sicer nebi pristal na objavo, zagotovo pa bi se našle tudi izjeme, katere bi se strinjale, da se lahko kdo na njihovi napaki nauči, kako se ji lahko sam izogne.

Lepo bi bilo, ampak od CSIRT tega realno nihče ne pričakuje. Se pa to lahko pričakuje in zahteva od vsakogar pri komer je do incidenta prišlo, CSIRT pa jim lahko pri tem pomaga.

SeMiNeSanja je 14. feb 2017 ob 00:16 izjavil:

Torej bomo spet ostali na suhoparnih statistikah o številu incidentov, ki pa predstavlja zgolj vrh ledene gore.

Suhoparne statistike lahko pripravlja tajnica s fax mašino in fikusom. Fax mašina je opcijska.

SeMiNeSanja je 14. feb 2017 ob 00:16 izjavil:

Kdor bo hotel poučne zgodbe, ta naj pa bere kakšnega Krebsa.....

Ne gre se za poučne zgodbe, temveč za primere dobre prakse. Primer dobre prakse kako se incident razdela. Kako se ne išče grešnih kozlov (gl. zgoraj komentar o "šalabajzerjih"). Kako se išče in odpravlja vzroke za napačna ravnanja ljudi. Kako se omejuje možnosti človeške napake. Kako se ... To je mnogo več, kot pa dobra zgodbica. To je meso tega, kar bi lahko polnokrvni CSIRT ponudil IT industriji v Sloveniji.

krneki0001 je 14. feb 2017 ob 00:44 izjavil:

AndrejO je 14. feb 2017 ob 00:36 izjavil:

krneki0001 je 13. feb 2017 ob 23:57 izjavil:

Oprosti, ampak ajpes so šalabajzarji.

Težke besede. Ampak to "šalabajzerstvo" je potrebno argumentirati, ne samo razpredati o temu, kaj vse naredijo banke, da jim oprostiš "šalabajzerstvo", potem ko še vedno zajebejo po celi črti.

Govorimo o ajpesu. Odpri temo o bankah, imam veliko za povedat. Med drugim tudi to, da bi se večina bank brez problema lahko "izplačala" in vrnila vse kar so dobili iz proračuna kot dokapitalizacije, pa se ne smejo, ker bi s tem ogrozili prodajo teh bank.

Če se ne motim, je beseda tekla o informacijski varnosti in (ne)verjetnosti, da pride do napak in incidentov v informacijskih sistemih.

Od kje si ti sedaj priletel notri z nekimi miljardami, ne vem. Vem pa, da si je npr. RBS s svojim "epic fail" IT-ja zagotovila kar lastno geslo na Wikipediji. Vajo so ponovili l. 2013. In potem še enkrat l. 2015. Pa to tudi ni bila edina banka, ki se ji je zalomilo.

Ampak glede na to, da se pogovarjamo o varnostnih incidentih, dajmo pogledati še kako je banka izgubila podatke o svojih komitentih, ki so bili na nekem USB ključku. Zadeve se včasih izgubijo tudi na pošti. Večkrat.

OK, razumem. Brati o pomankljivih procesih ni ravno najbolj seksi. Direkti napadi so bolj seksi. SQL injection napadi pa sploh.

Mnja. ECB jo je odnesel samo z manjšo prasko.

Anyway ... nekaj razpredati o splošni varnostni bank pač ne vzdrži vode in tudi ne pove ničesar o temu, če je bil AJPES malomaren, nespreten, zabit ali pa so imeli zgolj zvrhano mero nesreče.

AndrejO je 14. feb 2017 ob 01:02 izjavil:

...Vem pa, da si je npr. RBS s svojim "epic fail" IT-ja zagotovila kar lastno geslo na Wikipediji. Vajo so ponovili l. 2013. In potem še enkrat l. 2015. Pa to tudi ni bila edina banka, ki se ji je zalomilo.

Ampak glede na to, da se pogovarjamo o varnostnih incidentih, dajmo pogledati še kako je banka izgubila podatke o svojih komitentih, ki so bili na nekem USB ključku. Zadeve se včasih izgubijo tudi na pošti. Večkrat.

OK, razumem. Brati o pomankljivih procesih ni ravno najbolj seksi. Direkti napadi so bolj seksi. SQL injection napadi pa sploh.

Mnja. ECB jo je odnesel samo z manjšo prasko.

Anyway ... nekaj razpredati o splošni varnostni bank pač ne vzdrži vode in tudi ne pove ničesar o temu, če je bil AJPES malomaren, nespreten, zabit ali pa so imeli zgolj zvrhano mero nesreče.

Ja, ampak odgovorni za te zadeve so bili na banki in so leteli kot so dolgi in široki iz službe.

Pri nas se bo pa slo-tech demoniziralo in človeka, ki je vdrl v sistem in jim pokazal kakšno štalo imajo. Na ajpesu pa ne bo nič novega, še zadev ne bodo popravili, čeprav trdijo, da so jih že. Ne verjamem da v tako kompleksnem okolju lahko v parih urah daš ven popravek, tudi v parih dneh ne, ker morajo prvo preveriti, kaj je točno napaka, napisat specifikacije za zunanje jim jih dostavit in potem imajo zunanji vsaj teden dni časa, da naredijo popravek.
Predobro poznam te "dinozavre", ker sem v takem podjetju tudi delal. In ja da se tako podjetje obrne za par stopinj, rabiš enormen vzvod.

@Matthai

Je pač razlika ali se poskuša nekaj naredit, ali pa se poskuša diskreditirati pisca novice...

poweroff je 14. feb 2017 ob 09:26 izjavil:

krneki0001 je 13. feb 2017 ob 23:57 izjavil:

Stvar je čisto enostavna. Preden daš zadeve v produkcijo, je treba vse potestirat in narediti teste. Ker so podatki "kritični" je treba še toliko testov več. Penetration test je nekaj nujnega in se ga lahko tudi večkrat naredi, če se že greš edinega v javni upravi, ki ima vse baze registrov čez. Ker če se ve, da si edini s temi bazami, si toliko bolj izpostavljen.

Tukaj se strinjam z AndrejemO. Napake se dogajajo, tega se ne da preprečiti, noben sistem ni 100% varen, pomembno je, kako se odzivaš na napake.

Se strinjam da noben sistem ni varen, ampak danes "sql injection!!!!". Mislim prva stvar na vsakem faksu, kjer imajo podatkovne zbirke in osnovno učenje programiranja z bazami podatkov, te naučijo kako se izogneš sql injectionu (vsaj na FERI-ju v Mariboru je to kr pomemben del enega izpita).

In ajpes je edina javna ustanova z ogromnimi bazami, z vsemi podatki o vseh prebivalcih. Imajo vse. Ampak res vse o vsakem človeku (davčna, emšo, naslovi, premoženje,.... Vse fursove podatke (stanja, zaslužki, krediti,...), vse transakcijske račune, vsa stanja na teh računih (vsak večer se pošiljajo na ajpes), vse blokacije, vse transakcije,..., vse podatke bank, koliko so likvidne,.... Manjkajo samo številke gat (številke čevljev imajo). In v takem primeru narediš vsaj dva penetration testa od dveh različnih firm. In penetration test ponavljaš vsaj vsake pol leta.

Oprosti, ampak ti podatki so tako zelo pomembni in tukaj se nimajo kaj šalabajzersko obnašat. Sploh pa ne potem iskat krivca v slo-techu in človeku, ki je opozoril na njihove napake. Raje naj ga zaposlijo.

poweroff je 14. feb 2017 ob 09:26 izjavil:

Spominjam se nekega primera, ko sem v podjetju delal forenziko. Razvili so neko aplikacijo, ki je vsebovala res zelo občutljive osebne podatke. Direktor se je zavedal tveganja in je naročil varnostno analizo.

Ki je pokazala, da je vse OK.

Potem so podatki "ušli" na internet - z ustreznim Google iskanjem si lahko dostopal do zalednih podatkov.

Direktor je nemudoma naročil še eno varnostno analizo, ki je pokazala, da je aplikacija OK. Posumili so na vdor in s kolegom sva šla delat pregled.

No, v prvi minuti sem ugotovil, da so imeli neustrezen sistem avtentikacije - s spreminjanjem URL naslova si lahko brez gesla dostopal do zalednega sistema...

Fail?

Seveda.

Je direktor ravnal malomarno?

Po moje ne, problem je, da seveda ni imel dovolj znanja, je pa v okviru svojega znanja naredil vse, kar je vedel in znal.

To je razumljivo, da direktor ne ve vsega in dela po svojem znanju. Ta se je celo dvakrat potrudil. Problem je ker je naročil varnostno analizo pri šalabajzerjih, če si ti v minuti ugotovil napako pri avtentikaciji. Očitno je nihče ni šel niti preverjat.


Hint, če to bere ta, ki je vdrl, naj me kontaktira, ima službo zagarantirano. Naredim takoj firmo, ki bo opravljala penetration teste in opravljala analize, ker človek očitno obvlada.

thramos je 14. feb 2017 ob 10:46 izjavil:

poweroff je 14. feb 2017 ob 09:26 izjavil:

Seveda.

Je direktor ravnal malomarno?

Po moje ne, problem je, da seveda ni imel dovolj znanja, je pa v okviru svojega znanja naredil vse, kar je vedel in znal.

Neznanje ni izgovor, ali kako že gre.

Verjetno bi moral v takšnem primeru direktor ocenit, da zaradi svojega neznanja ni sposoben za upravljanje razvoja aplikacije, ki operira z res občutljivimi podatki.

Nope, direktor je ocenil, da nima dovolj znanja in je naročil zunanji varnostni pregled, kar je edina pravilna odločitev v tistem trenutku. Problem je bil samo, ker je najel napačne, ki niso odkrili že osnovne napake ob avtentikaciji.

Kdo je pa rekel, da vdorov v banke ni bilo? To samo ti trdiš.

Ampak v sloveniji boš zelo težko naredil kak SQL injection na naših bankah. Zelo težko. In to kar so naredili ajpesu, so začetniške napake v kodi, ki jih delajo študentje prvega letnika faksa, plačani 3 do 4 evre na uro.