Digitaliser.dk

Hej Stephan

Mange tak for dine kommentarer til OIOREST sikkerhedsmodellerne.

OIOREST beskriver i øjeblikket to sikkerhedsmodeller. Det er lidt uklart hvorvidt dine kommentarer går på begge sikkerhedsmodeller eller kun den ene. Endvidere er vi lidt usikre over, hvad du mener med ” uden interne isolerings- og fallbackmekanismer” og ” og opretholde den rene implementering”.  Kan du uddybe dette?

Formålet med OIOREST’s sikkerhedsmodellerne har været at leve op til lovgivningen på området. Datatilsynet har godkendt OCES certifikater som akkreditiv ved adgang til personfølsomme data, samt at SSL på den beskrevne måde kan opfylde personoplysningslovens krav til stærk kryptering af personfølsomme data. Derudover er der selvfølgelig også organisatoriske forhold, der skal etableres omkring håndtering af data. Den konkrete sikkerhedsløsning skal selvfølgelig tage udgangspunkt i en analyse af risici i den specifikke situation. Mener du, at lovgrundlaget ikke er tilstrækkeligt på området?

Du har ret i at sikkerhedsmodellerne forudsætter, at der er en vis grad tillid mellem serviceaftager og serviceudbyder. Kan du forestille dig at der er tilfælde, hvor der ingen tillid er mellem en serviceaftager og serviceudbyder i den offentlige sektor?

Hvis du har kendskab til åbne standarder og udbredte produkter, der understøtter formålsspecifikke nøgler og andre af de problemstillinger, du har beskrevet, vil vi meget gerne høre om dem.

Mvh.

Finn

Hej Finn.

Imødekommende svar men som addresserer mange spørgsmål.

For det første har vi i dag ingen åbne standarder inden for sikkerhed og sikre services. De er alle låst til en enkelt teknologi og typisk designet omkring særinteresser /typisk gatekeepere) på sikkerhedens bekostning. Det største problem er dog at de ikke rummer plads til kontinuert opgradering. Det eneste som er sikkert indenfor sikkerhed er at state-of-the-art today er legacy i morgen og forældet i overmorgen.

Man har delvist generisk åbne standarder. F.eks. SAML arbejder i princippet med isolering så længe man ikke stoler på IdP-enheden. Hvad er vigtigere så er XACML begyndt at se vejen frem mod overgangen fra den forældende identifikations-baserede "sikkerhed" til credential-baseret sikkerhed.

I OIOREST misbruger man ligesom i resten af OIO både OCES og SAML - istedet for at isolere den digitale signatur som en credential der (sjældent) bruges end-to-end og arbejde med formålsbestmt afledte nøgler, så maser man den Digitale Signatur ned i den basale adgangskontrol hvorefter intet kan sikres. Alle nodes akkumulerer risici. Hvad er værre - hvis blot en enkelt ryger, så skalerer sikkerhedsbrud fra server til server uden nogen former for fallback-mekanismer - SSO er som at designe med ønsket om totalt nedbrud.

Omkring servere, så skal du vende den 100% rundt. Jeg kan ikke forestille mig tilfælde hvor der ER tillid mellem 2 servere. Selvfølgelig har vi aldrig tillid til en server (eller noget andet for den sags skyld). Det er det samme som at sige at vi er ligeglade med sikkerhed. Sikkerhed er baseret på evidens, forebyggelse by design og evne til at repondere effektivt på sikkerhedsfejl - det drejer sig ikke om naive eller ideologiske antagelser uden grundlag.

Der er mig bekendt ingen eksempler på stærk kryptering indenfor OIO. Stærkt kryptering forudsætter end-to-end, dvs client-to-client. At sikre kommunikation mellem servernodes er nærmest ligegyldig når selve serveren ikke designes med sikkerhed for øje. Laveste fællesnævner sætter sikkerhedsniveauet og perimetersikkerheden holder ikke, dvs. at koble 2 servere på den måde skalerer sikkerhedsrisi..

Dvs. model 2 er klart fejlbehæftet fordi den i selve sit design gør alle servere til man-in-the-middle komponenter som ikke kan sikres og samtidig blokerer for sikre servers.

Designes serverne ordentligt så ligner model 1 blot en måske udvidelse af en fysisk server til at dække det sæt af servere som tilsammen hoster de delservices der tilsammen udgør den samlede virtuelle service. Problemet er at hvis det er identifikationsbaseret, så er der ingen isolering - dvs. f.eks. Borger.dk er grundliggende fejldesignet uden isolering eller nogen af de basale krav vi må stille til kritisk infrastruktur.

Inden man taler om virus-inficerede clienter (som den typisk dårlige undskyldning for ikke at tage sikkerhed alvorligt), så er det vigtigt at huske 3 ting.

a) Sikkerheden på clienten skal isoleres i et mobil og formentligt trådløst tamperresisten medium. Brugeren skal authenikere formålsspecifikt og selve transaktionen skal valideres af brugeren.

b) En server kan sagtens yde services uden at vide HVEM modparten er. Derimod hvis serveren ved hvem modparten er, så kan hverken modpartens sikkerhed eller serverens sikkerhed kan opretholdes. En formålsspecifik nøgle er en samling af credentials som beviser forskellige ting om modparten.

 Identifikation overfør en server er selve kilden til sikkerhedsbrud, men også til ineffektivisering fordi magten og kontrollen flytter fra behovet til udbyder.

c) Man er nødt til at designe mod noget bæredygtigt. Dvs. selv hvis vi har en masse dårligt designede services, så må man pakke dem ind og gradvist opgradere.

I dag skalerer problemerne eksponentielt fordi man ikke tænker sikkerhed ind i systemerne - endnu værre de fælles services og standarder ØDELÆGGER sikkerheden.

Jeg vil ikke kommentere Datatilsynet og den måde de forvalter rimeligt gode love på. Det oprindelige EU Data Direktiv fra 1995 var faktisk rimeligt, men forvaltningen af lovgivningen og omsætning heraf til praktiske løsninger har gennemgående været katastrofalt ringe - der er ingen trade-offs. Et problem der forværres af de ubegrunde undtagelsesbestemmelser som centraladministrationen har indført med "Adgang til Data" - man kan ikke løse et sikkerhedsproblem ved at ændre loven ligesom en lov ikke kan erstatte sikkerhed.

Igen - der er INGEN reelle trade-offs - tværtimod hjælper ordentligt designet sikkerhed med udgangspunkt i BORGERENS sikkerhed til at sikre at behovet styrer tilpasningen, dvs. forudsætningen for effektivisering og systemerne kan ikke have sikkerhed hvis borgerne ikke har det.

Håber det afklarer nogle af spørgsmålene

Stephan

Hej Stephan

Tak for svaret, som giver en større indsigt i din kritik af OIOREST sikkerhedsmodellerne, samt en forståelse af, at der er et rimeligt stort gab mellem den sikkerhed du ser som nødvendig, og den sikkerhed, som er mulig i dag med nuværende standarder, værktøjer og infrastruktur, og som vi ser som tilstrækkelig. Den sikkerhed, som du ser er nødvendig, kan ikke, set fra min stol, etableres indenfor en kort tidshorisont. Hvad skal vi så gøre indtil at verden (standarder, værktøjer, infrastruktur, leverandører, kunder, brugere osv.) er modne nok til din skitserede sikkerhed? 

Mvh.

Finn

Finn

Det er ikke spørgsmål om hvad der er "tilgængeligt", fordi det er de samme og kendte teknologier brugt med udgangspunkt i borgerens sikkerhed og at sikre at behovet trækker udviklingen og tilpasningen.

At kalde man-in-the-modeller i alle knudepunkter som umuliggør sikkerhed for "tilstrækkelige" kræver nok en hel del yderligere dokumentation end en simpel påstand. Jeg vil påstå det modsatte objektivt er tilfældet og argumenterne er ikke på de nuværende modellers side, når man selv pareto-optimalt kan forbedre sikkerheden.

Den nuværende tilgang ser reelt den offentlige sektor som et stort intranet uden intern sikkerhed på et tidspunkt hvor alle ved at perimetersikkerheden ikke holder. At gøre enhver offentlig server til en sikkerhedsbombe er ikke sikkerhed - det er det modsatte.

Men eftersom åbne semantiske standarder ikke er tilgængelige er det klart at man er nødt til at vælge en strategi herfra. Intet ændres fra den ene dag til den anden, men man kan lade være med at sigte efter en fordansket tilpasning af modeller man fra starten ved er uholdbare og legacy-skabende.

Et af problemerne er at digital forvaltning er den primære kunde, men en monopolkunde som skvævrider markedet. Hvis man vil være foran, må man jo også optage sig ansvaret for at vælge hensigtsmæssige veje fremfor at fare vild i blindgyder hvorfra der ikke er udveje.

Som det er nu vil valget af standardiseringsform blokere for udvikling og fremskridt. Dumt er et mildt udtryk herfor. Lidt som at sætte atomkrafterværker op som man ved er i seriøs fare for nedsmeltning.

For god ordens skyld  bør man også være opmærksom på at den ensidige centralisering og enhedsstandardisering er stik imod den siddende regerings udtrykte politik om frit valg og innovation. Man begår den typiske planøkonomiske fejl i den offentlige sektor at tro det drejer sig om at vælge EN standard, hvorefter alt fryses om den ufleksible legacy-model. Den umiddlebare fordel fortaber sig hurtigt i infleksibilitet.

Der er objektivt ingen grund til at vælge fælleskomponenter som blokerer for udvikling uden anden årsag end særinteressers usikrede tilgang til data.

Selvom det er en udfordring så må det være muligt at vælge en standardiseringsform som ikke blokerer for nødvendigt fremskridt samtidig med at man gør det nemmere at rydde op i meget af de gamle systemer.

Jeg kan kun påpege problemerne og pege på løsningsmodeller. Det er ikke en politisk styret, men en bureaukratisk styret process.