Senest kommenterede indhold

Af HW Jensen 
Re: Hatten af for DR

Lang tid siden jeg har læst noget så fornuftigt. Herinde på V2 hører vi jo fra alle dem der har de rigtige meninger og ved bedre, tilsyneladende uden nogensinde selv at have fået en blodtud eller to. Godt at høre at der er nogen der lærer af deres erfaringer, og fortæller om det uden skønmaleri. Jeg køber at det måske ville være endnu mindre siloagtigt at udviklerne selv var involveret i devops rollen så der simpelthen ikke var en devops afdeling. Men hvem ved, de sidder måske i det samme kontor eller et eller andet. At infrastruktur er lidt for sig selv er vel OK, det er jo trods alt et lidt andet perspektiv når platformen er så tung som jeg gætter på den er i DR.

Af Jesper Frimann 
Re: hmm hvornår sagde hun det ?

@Louise Klint

Hvorfor? Hvorfor tage afsæt i ekstern teori, når man nu har håndgribelige erfaringer med IT‐systemet, ude på afdelingerne, efter det er implementeret på hospitalerne?
Det er jo dem, der skal anvende systemet ‐ realisere ”gevinsterne” ‐ brugerne.


Det kræver ret meget erfaring at køre sådanne store projekter. Og det kræver også en veludviklet faglig kultur i den org. der skal køre projektet.
Man skal også have respekt for den faglighed i det fagområde man beskæftiger sig med, og der skal være 'nok' faglig ekspertise til rådighed sammen med 'nok' IT-faglighed.

Hvis man er heldig kan man have folk der har begge dele.
Altså sundhedsfaglige folk, der har IT forståelse/dybere erfaring/uddannelse eller IT-folk (meget gerne IT-arkitekter) der har dybere sundhedsfaglige forståelse/erfaring/uddannelse.
Disse kan typisk hjælpe til med at bygge bro og sikre at man kommer hele vejen rundt og får alt med.

F.eks. har der været skrevet en del om f.eks. manglende adgange for sygeplejersker til at bestille medicin/blodprøver m.m. Det var f.eks. så bare ikke tilfældet i det område på det hospital, hvor min kone arbejdede. Netop fordi de 'Sundhedsplatforms' konsulenter, der var med lige hos dem til at specificere adgange m.m., forstod de sundhedsfaglige problematikken, og fordi at de sundhedsfaglige folk, som f.eks. min kone (der jo er vant til at høre om IT fra sin Mand + venner og bekendte), forstod de IT-problematikken og havde egentlig ret godt styr på deres processer. Derfor var adgange og uddelegeringer, der næsten i første hug fra starten.
Det skal så siges at de sundhedsfaglige i familien (begge ledende sygeplejersker) er ret glade for sundhedsplatformen. De føler at platformen er hurtigere, giver bedre overblik, er mere stabil og bedre integreret.
Det største problem for dem er ændringer i arbejdsprocesser og at de mere 'størknede' medarbejdere har problemer med at lære nyt. Altså hele implementerings metoden.
At så de 'forkælede læger' må løbe hurtigere... ja.. det er kun et problem når de har brug for dem ;^/

Dog, det tilføjes at målene er ”dynamiske, således at de løbende revideres på baggrund af de erfaringer der indhøstes med Sundhedsplatformen.” Alle 26 mål skal være opfyldt inden for 5 år, og repræsenterer, som sagt, en minimumsbesparelse på kr. 250 mio. i 2019.
Jeg kunne dog ikke lige umiddelbart finde nogen beregninger på det…?

De ligger i den opdaterede business case, tallene er der. Ikke at de nødvendigvis har noget som helst hold i virkeligheden.

Problemet er igen at man skal spare 2% om året. Og det er ikke mere effektiv.. eller bedre behandling eller.. nej det er at spare 2%, for det er det KPI som finansministeriet kan forstå. 'Hva Koster'ern'

Hele den her finansministeriets diktatur man har i det offentlige.
Der er ikke noget galt i at blive 2% bedre hvert år, men det kræver jo autonomi og at man selv kan få lov til at styre tingene, planlægge og sprede '2% bedre' ud over flere år, at man ikke får påduttet 'politiske fokus områder' så politikerne kan blive genvalgt etc. etc.

Jeg har selv prøvet at sidde i det private som 'teknisk ejer' af forretnings koncepter, hvor kravet var en 25% forbedring per år i forhold til forrige års baseline. Og det gik så længe jeg havde friheden og midlerne til at gøre det der skulle til for at blive 'bedre og mere effektiv', og tage måske 40% to år, så 25% det næste og så ellers -5% det sidste. Det to første år kunne jeg så bruge de 15% overskydende på investeringer og videreudvikling, netop for at kunne blive bedre. (Jeg havde en rigtig god 'forretnings ejer' på den anden side).
Men jeg fik f.eks. problemer når, jeg skulle bruge outsourcing centre, for så skulle der pludselig 14 mand til at lave 2 mands arbejde... men lad os lade IT-skandalen i Sverige ligge.......

Men jeg mener at dem vi skal holde hovedansvarlige er og bliver politikerne i borgen, det er dem der vedtager 'micromangement pakker' til sundhedsektoren, det er dem der pålægger dem besparelser .. det er dem der giver dem midler.. det er dem der.......

// Jesper

Af Niels W. O. 
Vi må vente

Jeg synes betydeligt godt om ideen med, at alle vores devices spiller sammen, men det ser ud til, at vi må vente lidt endnu - desværre. Men mon det alligevel at tænke over det når man køber nye devices? Så man ikke skal udskifte ALLE devices (jeg overvejer selv http://xn--lavprisln-d3a.dk/) når det engang bliver aktuelt.

Af Peter Kyllesbeck 
øjenæblescanning ?

Er det en udvidet form for irisscanning?

Af Erwin Lansing 
Re: qwerty12345!

"Det værste tilfælde jeg til dato har oplevet, er en side som begrænser koden til 8 tegn."

Glem ikke de sites der kun tillader en 4-ciret pinkode. Ja, de findes endnu i 2017.

Af Niels W. O. 
fejl

fejl

Af Helge Svendsen 
Re: Hatten af for DR

DR er vel store nok til,at de kan sætte en advokat til at læse det med småt.

Af Niels W. O. 
Spændende

Det lyder helt utroligt, men særligt spændende! Er som idé langt mere tillidsfuld end Samsungs og det er derfor yderst spændende at følge med i, om det kan lade sig gøre.

Af Malthe Borch 
19 millioner requests per minut

Man må gå ud fra, at 99.9% af disse er read-only og bare handler om at læse en blok fra en fil på disken. Det er vist ikke en specielt svær opgave, selvom der naturligvis er et vist behov for at følge med i trafikken og begrænse forbrug/misbrug.

Af Peter Makholm 
Re: DK-CERT vs. NIST

Jeg synes i øvrigt, at DK-CERT's anbefaling om at visualisere graden af "uforudsigelig variation" med farvekodning eller lignende over for brugeren er en god og pædagogisk måde at tydeliggøre konsekvenserne af brugernes valg for dem selv.

De fleste tilgængelige widgets er mildest talt ringe og er ofte biased mod bestemte former for variation. Når de virker er det mere af psykoogiske grunde (nudging) end at de reelt set viser styrken af et kodeord.

Det er selvfølgelig værd at tage med, men skal holds op imod at nogle målinger direkte strider imod hvad der er gængs holdning til hvad et sikkert og let huskbart kodeord er.

Og nå nu ingen andre vil så: Correct horse battery staple

Af Allan S. Hansen 
Af Helge Svendsen 
Re: Hatten af for DR

Og Dels for at drifte et site med 19 millioner requests i minuttet, uden de store hiccups

.. som kunne være driftet hos en af mange på nettet, der ikke laver andet end den slags. Vimeo, youtube etc. og ikke bygget fra bunden ud fra NIH princippet.

Og så ville man ikke skulle kode DR apps til alle mulige apparater.

Af Jesper Frimann 
Re: Det handler altid om mennesker...

@Mads H. Danquah

Ja. :)
Det handler nemlig i høj grad om mennesker, og om hvordan man enabler dem til at udføre deres arbejde bedste muligt, i samarbejde med de mennesker de er afhængige af.

Og det er bekymrende når man opretter en separat afdeling til DevOps... det er jo IMHO lidt i modstrid med hele ideen.

// Jesper

Af Peter Hansen 
Re: DK-CERT vs. NIST

Grundlæggende handler det jo om, at jo mere "uforudsigelig variation" et password indeholder, jo bedre, men det er åbenbart for abstrakt et begreb til, at almindelige brugere kan forstå det jfr. DK-CERT's vejledning.

Det er klart modsatrettede anbefaliger til hvad en "Verifier" bør kræve.


Ja men hvis man til gengæld læser denne NIST-anbefaling bogstaveligt:

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:
• Passwords obtained from previous breach corpuses.
• Dictionary words.
• Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
• Context-specific words, such as the name of the service, the username, and derivatives thereof.

If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.

... kunne man rent teoretisk ende i et scenarie, hvor HIBP's liste over password-hashes bruges som grundlag for at afslå et ønsket password. Det vil i praksis nok have en endnu mere negativ effekt end DK-CERT's relativt fremkommelige krav til sammensætningen.

https://haveibeenpwned.com/Passwords

Jeg synes i øvrigt, at DK-CERT's anbefaling om at visualisere graden af "uforudsigelig variation" med farvekodning eller lignende over for brugeren er en god og pædagogisk måde at tydeliggøre konsekvenserne af brugernes valg for dem selv. Så er det et åbent spørgsmål, om man oven i det skal forbyde de ringeste passwords.

Af Peter Makholm 
Re: DK-CERT vs. NIST

NIST skriver:

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.

DK-CERT skriver:

Et password skal bestå af en kombination af bogstaver, tal og specialtegn.

Det er klart modsatrettede anbefaliger til hvad en "Verifier" bør kræve.

Af Casper Olsen 
qwerty12345!

Sådan - så opfylder jeg Dashlane krav til passwords, endda brute force sikret...
(Stærk ironi forekommer, og ja koden ville til dels virke fint med 2FA)...

Når det kommer til passwords, så det værste faktisk de sider, som begrænser længen af ens kode til fx 16 tegn. Jeg kan godt li' lange koder, og har ikke et problem med at huske dem.

Det værste tilfælde jeg til dato har oplevet, er en side som begrænser koden til 8 tegn. De har endda været så flinke også at begrænse input feltet til kun at tillade samme antal, så man opdager ikke bare sådan lige når man taster sin kode, med mindre man er 110% opmærksom...

Af Peter Makholm 
Re: DK-CERT vs. NIST

NIST siger derimod, at der er ingen grund til at kræve en blanding


Hvorimod DK-CERT udsender en pressemedelse hvor de fremhæver at websteder bør have et krav om at blæande bogstaver, tal og specialtegn.

Men de anbefalinger er baseret på, at flere og flere virksomheder tilbyder 2FA.

Hvilket også er blandt de fem anbefaligner som DK-CERT fremhæver.

Af Ivo Santos 
Amerikansk sw, og kina hardware!!!

Euro borger til Europæiske selskaber: Hold jer væk fra amerikanske sikkerheds selskaber.

Se den tekst giver også mening, men!!, men, hvad med f.eks. amerikansk software eller kinesisk producerede hardware!!??.. Se det er også et godt spørgsmål!!!

Af Malthe Høj-Sunesen 
Re: DK-CERT vs. NIST

NIST siger jo ikke, at man ikke må blande bogstaver og symboler.

NIST siger derimod, at der er ingen grund til at kræve en blanding - men at man som bruger bør kunne bruge alle ASCII-tegn, også ikke-synlige tegn, og emojis. Samtidig skal der hellere lægges vægt på at kodeordet er langt (mindste anbefalede maxlængde er 64 tegn, gerne længere) end at det er kompliceret.

Men de anbefalinger er baseret på, at flere og flere virksomheder tilbyder 2FA.

Helt præcist siger NIST: "Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well. [...] Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.", https://pages.nist.gov/800-63-3/sp800-63b.html#sec5

Bemærk hvad SHALL, SHOULD og SHOULD NOT betyder: "The terms “SHALL” and “SHALL NOT” indicate requirements to be followed strictly in order to conform to the publication and from which no deviation is permitted. [...] The terms “SHOULD” and “SHOULD NOT” indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited.", https://pages.nist.gov/800-63-3/sp800-63-3.html#def-and-acr

Af Allan Ebdrup 
Hatten af for DR

Dels for at stille sig op og fortælle om deres DevOps indsats. Jo mere vi deler med hinanden, jo mere kan vi lære.
Og Dels for at drifte et site med 19 millioner requests i minuttet, uden de store hiccups. 👍

Af Povl Hansen 
Re: Omvendt ?

Det er så mig selv

Det kan være af de skal spare og kun aflytter størrrre udbydere ;)

Af Povl Hansen 
Peter og Ulven

For meget larm
Google skal også passe på af de ikke laver så meget larm af brugeren bare bliver vant til larmen og til sidst holder op med af ligge mærke til den

Nogen der gider af sende en kopi af Peter og Ulven til en eller anden ansvarlig hos Google ?

Af Gert G. Larsen 
Og vi stiller for få krav til DKCERT

Hvad er DKCERT efterhånden for en størrelse?
Hvem betaler dem?
Hvad kan de?
Hvem bruger dem?

Er de ikke et levn fra 80'erne, dengang Preben Andersen fangede hackere?

Af Povl Hansen 
passwords :(

Jeg er lige glad
hvis jeg skal hente en prøve version af Photoshop skal jeg oprette en bruger
hvis jeg skal købe en CD på nettet skal jeg oprette en bruger

så hvis nogen af de 37 forbrugerrettede og 11 virksomhedsrettede er ovenstående steder så er mit meget hemmeligkode ord nok noget i stil med "qwerty" da det er en konto jeg er lige glad med og ikke har nogen planer om af bruge mere

Kunne man ikke også lave et krav om af sider ikke må kræve konto oprettelse, hvis man ikke har nogen som helst af bruge den konto til , se det ville være en regel som jeg syntes ville være brugbar

Af Mads H. Danquah 
Det handler altid om mennesker...

Jeg tænker der er mange idéer til hvad "DevOps" skal forbedre i DR, men mon ikke de store er

  • Det manuelle arbejde i udvikling, test og drift skal reduceres så man kan rulle ting ud hurtigere med højere kvalitet
  • Ansvaret for at tinge bliver udviklet og bliver ved med at virke skal bredes mere ud

Den første ligger lige til højrebenet for et automatiserings-team. Man kan lave workshops med de teams skal hjælpes hvor man konfigurer værktøjer og man kan hive konsulenter ind til de helt skumle hjørner af AWS. I det hele taget kan man nu om dage få lavet noget rigtig lækker automatisering.

Men - automatiseringen er altså de 20 (meget shiny) procent "DevOps" - de resterende 80% ligger i alle barrierer der er opbygget af personlige konflikter, siloer opbygget af kamp om budgetter, ar fra alle de gange hvor drift skulle holde dårligt kodede stumper i luften under højt load osv osv. Med andre ord, alt det nitty-gritty hvor man skal få folk til at arbejde sammen om at lave noget, og derefter i fælleskab have ansvar for hele produktet.

Jeg synes det er lidt svært at læse ud af artiklen hvordan det her DevOps team reelt skal få udbredt den slags samarbejde, og hvis de tanker allerede er på plads kunne det være super spændende at høre mere om dem.

Hvis de ikke er på plads kunne det være spændende at høre om hvordan de kommer det :)

Og som et ps jeg kan varmt anbefale at alle der vil have en let spiselig indføring i problemerne DevOps omhandler (hvis man spørger nogen af dem der startede det hele that is) læser/hører "The Phoenix Project"

Af Peter Hansen 
Re: Køb dansk

Jo mere lokalt man kan få sine sikkerhedsprodukter, jo bedre kan man sikre sig mod dette problem.


Vil det sige, at hvis NETS havde valgt en dansk leverandør i stedet for IBM, så ville deres kunders private forbrugshistorik ikke være blevet solgt af en betroet medarbejder til den kulørte presse?

Anbefalingen synes heller ikke at kunne forklare, hvordan belgiske erhvervskunder hos Belgacom kunne have sikret sig imod, at GCHQ infiltrerede Belgacoms sysadmin mhp. at aflytte deres kommunikation.

Af Peter Makholm 
DK-CERT vs. NIST

Jeg hæfter mig lidt ved regl nummer 2 om at et kodeord skal bestå af en kombination af bogstaver, tal og specialtegn. Dette er som jeg forstår det i modstrid med den seneste 'Digital Authentication Guideline' fra NIST.

Er der en jounalist der kunen bruge 5 minutter på at ringe til DK-CERT og få dem til at uddybe denne afvigelse? Er det et bevidst valg at man fastholder denne anbefaling eller er man bare mere konservative end NIST?

Af Anne-Marie Krogsbøll 
Det sete afhænger åbenbart af øjnene, der ser...

I hvert fald ser det ud til, at der er nogen (helt uvildige?), der ser Sundhedssplatformen som et vellykket projekt:
http://diku.dk/begivenhedsmappe/begivenheder-2017/konference-gode-offent...

Er der nogen af de nævnte talere, som repræsenterer lidt mere kritiske røster - eller er der tale om en ren spin-konference?

Der er sat 20 minutter af til hver taler - det lyder vældigt dybdeborende. Til gengæld er der sat 50 minutter af til afsluttende networking - er det der, næste rotationsrunde med deraf følgende kæmpe gyldne håndtryk og aftrædelsesgodtgørelser aftales? Mon det er dette punkt på dagsordenen, der er konferencens egentlige kerneopgave?

Af Kjeld Flarup Christensen 
Køb dansk

Jo mere lokalt man kan få sine sikkerhedsprodukter, jo bedre kan man sikre sig mod dette problem. En forretningsmodel kunne være at source sikkerhedsprodukter på source niveau, og sælge sit eget "danske" produkt.

Generelt er det noget skidt at fremmede efterretningstjenester kan snige sig ind via produkter. Og TDC's mobilnet er jo leveret af kinesiske Huawei. Ericsson blev smidt ud på prisen, da man mente at pris betød mere end lokal troværdighed.

Af Jesper Hansen 
DevOps, ikke Dev eller Ops..

DR er så endnu en i rækken der smider en udviklere ind i et team, kalder det "DevOps", og så er de pludselig gode til operations. Forsøget med at lægge det i infrastruktur teamet, viser også meget godt at man ikke forstår begrebet.

DRs jobannoncer viser det også meget godt. "Vi søger en DevOps udvikler"... wat?