Der er klart en mangel på dygtige specialister indenfor for specifikke områder.
Men den største udfordring er faktisk, at IT folk generelt ikke følger best-practice og anbefalinger - som alle leverandører mv. løbende frigiver og opdaterer. Så det er ikke fordi viden ikke findes, den bruges bare ikke.
Og jeg troede ellers at CFCS var tilsynsmyndighed på området...
Der har vist sneget sig et par faktuelle fejl ind i denne artikel. Så vidt jeg ved, så er det fx helt frivilligt at deltage i testen.
Et første skridt kunne være automatisering af konsulent rapporter. Min vurdering er, at der er en rigtig god business case i at erstatte rapporter fra McKinsey & Company med AI, Big Data samt ikke mindst http://www.itu.dk/people/sestoft/center.html:
Omstillingspotentiale: Hvis man justerer ordforrådet og tilpasser lix-tallet, kan rapportgeneratoren formentlig bringes til at generere evalueringsbilag, høringssvar, strategiplaner, kvalitetsudviklingsrapporter, essays om postmodernisme, OL-reportager og lignende dokumenter.
:-)
Der er en del deltajer omkring DNB's godkendelse og forbehold, som i ikke har fået med. Det er lidt mere kompliceret end som så.
Ville være super hvis i generelt kunne linke til jeres kilder.
Tiderne er skam helt sammenlignelige, som fx en RSA-SHA1-PKCS1 signatur med en 2048 bit nøgle m/u CRT af en 1024 byte buffer m/u blinding. Kommentaren går på, at man i visse dele af OpenSSL har fokuseret mere på asm optimeringer end algoritmiske. Compilerne har jo også udviklet sig siden 1998 og er blevet væsentlig bedre til at generere kode. Dermed selvfølgelig ikke sagt, at man ikke kan hente noget med asm. Men det skal ses i sammenhæng med mange andre faktorer. Your mileage may vary.
Ja, samt en masse andre implementeringer.
I forhold til PolarSSL, så fejler denne i andre sammenhænge - se fx "Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations".
Faktum er at der til stadighed findes fejl i de forskellige implementeringer. Derfor er review og test et kritisk element i udviklingsprocessen.
Et relativt unuanceret indlæg, der over en bred kam sammenligner æbler med pærer. Hvad er bedst: Windows eller Linux? Det kommer an på...
Kan man også sammenligne madvarer på denne måde? Er Netto's discount produkter sammenlignelige med friske råvarer fra køkkenhaven tilberedt i ens eget serverrum^^^køkken? Det kommer vel an på...
Den store (og spændende!) udfordring i dag er, at finde det rette miks af egne løsninger og cloud løsninger i forhold til ens virksomhed. At tro at cloud løser alle udfordringer er naivt.
Er det ikke lige præcis derfor USA vedtog PATRIOT Act? Denne lov angiver bl.a. at udenlandske datterselskaber til amerikanske firmaer, som fx CSC DK, har pligt til at udlevere oplysninger til "nationens sikkerhed". Udenlandsk lov kommer så i anden rækkefølge - jeg antager USA ikke går så meget op i den danske persondatalovgivning.
Der skal, som regel, mere end bare et par "enkelte DNS-ændringer" til.
DMARC består af SPF og DKIM. SPF kan konfigureres DNS, men det kan DKIM ikke. DKIM kræver at den (eller de) udgående mail servere påtrykker alle mails en digital signatur. Den offentlige nøgle distribueres via DNS. Og det er, desværre, ikke alle mail servere, der understøtter DKIM (nogle understøtter fx kun den gamle DomainKeys standard, andre slet ikke noget).
Hvis man i stedet bruger en cloud leverandør, som fx Google, så er det relativt nemt at implementere DMARC (NSA^^^Google passer forhåbentlig godt på den private nøgle). Hvis man bruger fx Office 365, så kan man kun implementere SPF.
Men en ting er at implementere DMARC, en anden ting er at få folk til at håndhæve reglerne (dvs. modtagerne skal også gøre brug af standarden)...
Men målet og gevinsten ved DMARC er vi naturligvis ikke uenige om :-)
For at citere Peter Gutmann:
And while you're lying awake at night worrying whether the Men in Black have backdoored the CPU in your laptop, you're missing the fact that the software that's using the random numbers has 36 different buffer overflows, of which 27 are remote-exploitable, and the crypto uses an RSA exponent of 1 and AES-CTR with a fixed IV.
Sætter lidt perspektiv på TDC's planer om at outsource til Huawei (uanset om Huawei lufter muligheden for et udviklingscenter i Danmark #salgsteknik).
For langt størstedelen af brugerne byder Java ikke på noget funktionalitet ud over NemID.
Der er sikkert heller ikke så mange som kører Secunia's Online Software Inspector (OSI), der som bekendt også kræver Java.
Jeg er helt med på udfordringerne, men hvordan vejes dette op i forhold til fx lovgivningen mv.? Hvordan beskytter fx Roskilde Kommune personfølsomme oplysninger: er det helt op til brugerne? Og hvad vil der ske skulle noget "gå galt"?
Andre typer af virksomheder ligger under andre former for krav til compliance.
Imponerende antal nordiske brugere alt taget i betragtning? ;-)... 30 millioner skandinaviske Netflix-brugere ...
Dette angreb er ikke rettet mod AES men mod block ciphers (herunder også fx DES og 3DES) i CBC mode - mere specifikt SSL protokollens brug af initialization vectors (IV). Da stream ciphers som fx RC4 typisk ikke benytter sig af initialization vectors / CBC, men bare benytter ren XOR, er de umiddelbart ikke berørt.
Sjovt nok benytter Secunia selv Java til deres Secunia Online Software Inspector (OSI).
"Invincibility lies in the defence; the possibility of victory in the attack."
- Sun Tzu
Gad vide om det også omfatter Siemens' efterhånden ret omtalte SCADA systemer - hvem sagde Stuxnet? :-)
Martin Clausen