Codan valgte den store desktop-virtualisering

Jan Kaspersen skrev:
jeg kan VIRKELIG IKKE se problemet, og hvis ,an nu har sit lukkedet net som man bruger ICA/SSL over hvad er forskellen så ? det kan være at min praktiske erfaring ikker kan leve op til din teoretiske baggrund,- men jeg mener at ha fat i den "lange" ende..

go weekend

Michael Nielsen skrev:
Det er sjovt, hvordan centralised-distributed bliver byttet, sådan set hver 5-10 år.

Stephan Engberg skrev:
Mads

Jeg påpeger masser af alternativer, men ikke i en principiel diskussion. Dem som ser denne type problem som en quickfix har end ikke fattet de mest simple problemstillinger. Det skalerer jo ehel vejen til multi-id borgerkort etc.

Jeg påpeger klokkeklart hvad der skal til - al nøglekontrol og basiskryptering klient-side. Alle fysiske og legale objekter skal virtualiering overfor serversiden. Interfaces skal være modeldrevet interoperable. De højere lag skal være semantisk interoeprable.

VDI er sikkerhedsmaæssigt på alle måder noget klamhuggeri som ikke kna bruges hvis man etablerer risici for eksterne parter serverside.

Omkring virksomhed, så var det en legal betragtning. Så længe kun virksomheden selv rammes må den gøre hvad den vil.

VDI er et skridt ned ad stigen tailbage mod en forældet mainframetankegang. Vi dksl distribuere- IKKE centralisere.

Men første og vigtigste sikkerheds- og markedserkendelse er at server-side sikkerhed er en død sild. Antag serveren er hacket - og hvad så. Enten har man styr på fallback for alle parter eller også begår man grove fejl.

Kasper og andre glider let og elegant udenom med nogle TOTALT LIGEGYLDIGE henvisioner til et visse klienter er usikre. Det er en grov fejl at reducere sikkerhedssprøgsnpl til hvor meget man fra centralt hold overvåger, når det centrale system ikkerhedsmæssigt er et blødende sår.

Marc Munk skrev:
Stephan det du vil frem til er ganske simpelt at alt data bliver krypteret på klienten inden det ramme serveren ikke? Har du overvejet hvilke bivirkninger det kunne have i det daglige arbejde?

Stephan Engberg skrev:
På ingen måde - service-applikationen skal kende indholdet, men klienten skal kontrollere kontekst, dvs. enhver mulighed for at henføre data til den fysiske verden.

Kryptering har primært til formål at lukke de magt- og kontrolfokuserede gatekeepere ude af transaktionen.

Se her som en specifik men samtidig kompleks case i sundhedssektoren som strækker helt fra ambient til cloud.
http://www.ambafrance-dk.org/ (...)

Det som folk har svært ved er abstrahere fra det specifikke til at biholde principperne i det generelle.

Desktop virtualisering uden stærk klient virtualisering er det samme som at smide håndklædet i ringen, operationen lykkes, men patienten dør.

Marc Munk skrev:
Dit link henviser blot til en præsentation af dig selv?

Marc Munk skrev:
Hvis jeg så har forstået dig korrekt nu så er det kun klienten der må koble data sammen om den enkelte kunde. I det her tilfælde en forsikringstager?

Stephan Engberg skrev:
Det er hovedprincippet

Men man kan ikke gøre det så sort/hvidt i alle tilfælde. I forhold til specifikke applikationer og med sikring af frit valg vil man skulle have nuancer som skal tilføjes.
Den konkrete reference ovenfor illusterer hvordan kommunikationslagene selv i den nuveaærende kartels-styrede infrastruktur kan reetableres uden at gå på kompromis med hverken patient safety eller it-sikkerhed.
Men det er ikke alle aspekter som er omhandlet - f.eks. er der intet forsøg på at diktere din klient-side nøglekontrol - casen addresserer de tunge balancer, men resten er relativt enkelt og kan implementeres på mange måder.

Det skal bare ske på transaktions/applikationsniveau og semantisk interoperabelt - ikke som her (VDI/cloud kan ikke isoleres til et lag fordi de nestes).

Du kan sagtens laveforsikringspplikatiorene, så hverken forsikringsagenten eller kunden er identificerbare i serverapplikationerne, men du skal stadig have alle sikkerhedsaskepter med i designet f.eks. forsøg på gentagen forsikringssvindel.

Ligesom du kan i sundhedssektoren, hvor ingen server må KUNNE (all inclusive) henføre en specifik EPJ til en specifik patient. Den information er isoleret forbeholdt de direkte involverede i behandlingen.

Vi ved alle at det er langt fra dne virkelighed, vi lider under. Men det er præcis hvad der skal til for at genoprette den behovsdrevne innovation og sikre den verden vi hastigt er på vej ind i.

Stephan Engberg skrev:
Marc

Det er ikke hovedcasen, men bemærk vinklen til retsikring af det såkaldte DNA Register.
http://www.ft.dk/ (...)

Bemærk også hvordan Justitsministeriet i spin-svare misinformerer Retsudvalget. Svaret er selvmodsigende vrøvl.

Jan Kaspersen skrev:
jeg er enig i at:

VDI gør hverken data mere eller mindre sikker iforhold til brugeren/proigrammer

[b]Stephan Engberg skrev:[/b
Marc

Codan arbejder med stærkt sensitive data som sundhedssektoren - ofte fra sundhedssektoren i forbindelse med f.eks. livsforsikringssager og arbejdsskader, samt sensitive4 corporate data såsom risikoanalyser, IPR-rettigheder etc.

Men derfra og så til at sige hvordan Codan bør agere kræver en nærmere analyse. Og eftersom Codan er en privat virksomhed, vælger de til en vis grad selv hvordan de vil agere. Det gælder dog ikke håndtering af data om tredjepart, fordi her gælder som ved Aftaleloven rammer omkring hvad der er acceptabelt.

Desuden er forsikring ikke en simpel operation hvor man normativt kan optimere sikkerheden - alene grundet den stærke interessekonfllikt mellem forsikringsselskabet umættelig informations"behov" (hvad er ikke relevant?) og kundens interesse i at få en forsikring som dækker uden at krav afvises på "teknikaliteter", når behovet er der.

Det starter blot med at konstatere at man i hvert fald ikke indenfor dette setup KAN lave løsninger med forebyggende sikkerhed - det afhænger 100% af nogle firewalls som vi ikke kan have tiltro til. Lad os her undlade at komme ind på hvem som udgør den største risiko.


Omkring koblingsmuligheden mellem forskellige kontekst - det kan organsieres på mange måder ligesom man skal huske på at der er flere interessenter her. Rent logisk ligger denne kobling KUN i dit nøglekort eller "borgerkort", men afhængig af brugerinterfaces har du selvfølgelig behov for at flytte funktionalitet til både den lokale device e.g. "tyk" klient og gerne til online (hvad enten vi taler det interne serverrum eller det oursourcede "cloud" som selvfølgelig skalerer problemet en faktor mange)


Sikkerhedsdiskussionen er stærkt præger af at mange betragter sikkerhed som noget med at beskytte et system mod brugeren (identifikation, prfillering og overvågning). Men det er ret nemt (kan reduceres til ansvarliggørelse plus specifikke valideringer) i forhold til at beskytte brugerne mod systemet og herunder specielt misbrug af systemet når perimetersikkerheden fejler.

VDI og speicelt cloud er 100% perimertersikkerhed og den må betragtes som ikke-eksisterende fordi den hastigt eroderes og under alle omstændigheder konktrolelres af andre parter end den sårbare.

Stephan Engberg skrev:
Marc

Dit spørgsmål indikerer at du ser det som simple quick-fix alternativer !?

At man sikrer serverside ved at isolere transaktionen via nøglekontrol klient-side betyder ingen form for reduktion i servicemuligheder. Men selvfølgelig vil man ikke lave applikationer helt på samme måde.

Serverside er alligevel afhængig af nøglesikkerheden klientside, men ved at have flere nøgler kan du isolere serverside transkationer når de uundgåelige brud finder sted.

Jeg tager blot skridtet fuldt ud og erkender at det i i tilfælde af sikkerhedsbrud ikke er nok men nøgle-revokation, hvis man ikke også kan lave reel datarevokation. Det kan man oftest, men ikke altid - f.eks. er det naivt at antage at en tæt rådgiver ikke har en direkte og personlig relation selvom server-side systemerne ikke trustes med den samme information.

Problemet er at det kan man ikke med VDI og cloud. Her blotlægges alle nøgleoperationer i princippet online i et miljø som ikke kan sikres. Sikkerhedsmæssigt er det et gigantisk skridt baglæns fordi det netop skalerer risikoen og blokerer for løsninger.

I princippet ville den eneste måde at sikre Codans systemer derefter være at behandle dem som brudt på forhånd og dermed eliminere enhver form for henførbarhed til de sårbare personer eller virksomheder.

Hvis du mener at det er realistisk, så go for it. Hvis ikke så skal man styrke sikkerheden klient-side som den eneste måde at isolere og sikre transaktioner serverside.

Marc Munk skrev:
Og så kunne du jo også lige fortælle hvorfor du bliver ved med at skrive at VDI og cloud er det samme?

Marc Munk skrev:
Nu kan man godt sikre transaktioner serverside? De uundgåelige brud på sikkerheden er ikke begrænset til serversiden... Det ved en hver med en smule forstand på sikkerhed.

Marc Munk skrev:
Men du svarede ikke på mit spørgsmål hvad er til hinder for at en skadesmedarbejder misbruger sin adgang ved hjælp af den adgang de får når jeg skal melde en skade?

Stephan Engberg skrev:
Applikationen definerer minimum risikoen som jeg må vælge at acceptere eller helt fravælge servicen. Oftest er problemet at applikationen er sikkerhedsmæssigt primitivt designet, så man har designet med langt større risiko end tilsigtet.

Hvis jeg er afhængig af min læge, så må jeg stole på min læge - men KUN min læge og ikke alle læger eller hele sundhedsvæsenet. I praksis sker det ved at lægen har merviden om en ikke-personhenførbar Patient Journal som godt kan shares serverside af hensyn til tilgængelighed og sekundær brug af ikke-personhenførbare data.

Sker der en læk fra lægens side, så kender man kilden præcist. Men lægen kan i så tilfælde kun skade hans egne patienter og ikke alle patienter, dvs. risikoen er isoleret til dem som har valgt den pågældende læge som en betroet part.

Det problem har man langt fra i alle applikationer - den typiske applikation har slet ikke behov for at vide hvem kunden er. Det er et sikkerhedsmæssigt fejldesign i en verden hvor serverside sikkerhed forudsigeligt fejler.

Kort sagt applikationen betyder at du til tider må stole på en person, men det er en klokkeklar designfejl at stole på en server.

Når Toyota straffes og må tilbagekalde 8 mio biller grundet en risiko i en speeder, så det vand ved siden hvad it-fejldesign burde koste.

Hvis vi antager at man naturligt begynder at ville designe sikre applikationer - specielt et forsikringsselskab burde være blandt de første - så vil man selvfølgelig ikke løbe unødvendige risici hverken internt eller på kundernes vegne.

I dag laver man faktuelt ikke applikationsudvikling som optimerer value/risko - vi er snarere i en situation hvor risikoen maksimeres grundet særinteresser om at etablere magtkonstruktioner på kundens og markedets bekostning.

Med VDI ødelægger man muligheden for kontekstisolering hvor man eksternt fra kan stole på en medarbejder (en konkret rådgiver/sagsbehandler/taksator. Dvs. man må vurdere hele systemet inkl. alle medarbejdere som online og brudt by design.

Marc Munk skrev:
Det er ualmindelig svært at stole på folk. Der er en vis status i at vise at man kender til noget som andre ikke gør.

Marc Munk skrev:
Og hvad gør vi så når en del af den viden den enkelte læge har faglig relevans der burde være tilgængelig ved et besøg hos vagtlægen?

Marc Munk skrev:
Kan du ikke give et eksempel på et applikation der er designet efter dine ideer?

Marc Munk skrev:
Det er ualmindelig meget lettere at kritisere end at selv at diske op med noget konkret til at løse et givent problem. Det eneste du har vist indtil nu har været meget abstrakt.

Stephan Engberg skrev:
Der er mange varianter mellem det helt sikre og den helt usikrede cloud model.

Codan gør hvad Codan vil - efter denne øvelse ved du bare at de ikke kan sikre deres databehandling fordi de er tæt på online modellen uden mulighed for at ansatte kan isolere transaktionerne.

Det er paranoia og dobbelte standarder.

Det er nemmere at stole på at setup hvor der kun er specifikke navngivne folk, man skal stole på - end et setup hvor man skal stole på alle i et system som ikke kan sikres mod tredjepart.

Så har patienten nøglen til at give adgang. No problem.

Et folketingsvalg, GPS navigation, fysiske kontanter, Broadcast radio/TV, listen er lang.

Af egne bud i produktion kan jeg pege på RFID (www.rfidsec.com),

Annonceret men endnu ikke færdigudviklet er Sikring af blod/vævsprøver (se http://www.ambafrance-dk.org/ (...)) og håndtering af akut nødhjælp F.eks. side 11 og 18 her
http://www.ktn.qinetiq-tim.net/ (...)

Så du mener at det er mit ansvar at står klar med et quickfix alternative til ethvert af de mange brud på de helt basale principper som grådige kontrolfreaks iværksætter?

Beklager at jeg ikke har løsninger produktionsklar til alle applikationer og Borgerkort - det er svært når staten og infrastrukturen modarbejder sikkerheden for at optimere deres egne interesser.

Vi kunne være langt videre hvis vi ikke skulle slås mod samfundsundergravende tiltag som NemId, DokumentBoks, Borger.dk og gatekeeperne i tele- og banksektoren.

Det ville være en hel del nemmere hvis magtmonopolet begyndte at varetage ansvaret og understøtte samfundet.

Både for mig, for dig og for Codan.