Helt af interesse: Kan du uddybe det?
"procesautomatisering" - hvilke typer processer? Hvilke dele af processen kan automatiseres ved hjælp af en blockchain? Hvordan er denne automatisering anderledes end automatisering ved hjælp af andre teknologier?
"unødvendige mellemled" - hvordan er blockchain i sig selv ikke et mellemled? Hvordan vurderer man, om et mellemled er unødvendigt? Og lidt provokerende: Hvis mellemleddet reelt er unødvendigt, så skal det vel ikke erstattes af noget nyt, men bare fjernes?
"forbedre produktivitet og ydeevne" - hvori ligger de forretningsmæssige gevinster set i forhold til fx en kontinuerlig modernisering af organisationens digitale processer baseret på etableret best practice? Hvordan kan blockchain forbedre produktiviteten? Hvordan kan blockchain forbedre ydeevnen? Hvad forstår du her ved ydeevne?
Som sagt, så er det helt af interesse - gode svar kan hjælpe med, at udsagnet ikke blot fremstår som en floskel.
Hvis blockchain er en disruptive teknologi, så må der være en gevinst med minimum en faktor 10 i forhold til eksisterende teknologi. Det er det, jeg endnu savner at få konkretiseret - decentralisering ser jeg ikke i sig selv som noget, der giver it-driften en forbedring i den størrelsesorden, men det er måske netop fordi, valutaer og JPEG's forplumrer billedet?
(Sammenligning med skepsis over for automobilet og internettet er måske ikke så heldige - jeg er næppe den eneste, der begynder at mene, at begge dele var en fejltagelse ;-) )
Det undrer mig mest, at en udvikler har siddet i 2010'ish og kodet en dato med kun to cifre til årstallet. Y2K blev åbenbart hurtigt glemt.
YYYYMMDDHHMM ville have fanget problemet med at forsøge at bruge en 32 bit signed int med det samme.
Men det kan være, de var tilfredse med i det mindste ikke at have byttet om på måneder og dage...
Jo - test skal ligne virkeligheden ellers er det ikke en test!
Men i en test gælder det ikke om at finde frem til en besked, der rammer et maksimum (det er i hvert fald svært at bruge til noget). Det er mere relevant at finde frem til bundniveauet. Altså den ringeste phishing-mail, der kan slippe forbi spamfilter og andre tekniske foranstaltninger og stadig snyde et antal brugere.
På den måde har du et målepunkt, så du næste år kan sammenligne og se, om din indsats har hævet bundniveauet.
Hvis du vil bruge en meget effektiv phishing-mail, så skal det være som udgangspunkt for en dialog med medarbejderne i din awareness/adfærdsindsats. Og så er det dumt at vælge et format, der gør dem vrede. Så vil de ikke være modtagelige.
Her kunne man have lokket med andre ting end penge (og vel at mærke penge knyttet til deres ansættelse og ikke fx et falsk lotteri). En mail om at gå ind og vælge årets firmajulegave havde nok været mere ok.
Jeg ville dog aldrig selv anbefale at bruge madding, der "støjer". Det er en dårlig phishing-mail, hvis folk begynder at tale om den på kontoret med det samme. En angriber skal lige bruge lidt tid at udnytte den første adgang til at køre det egentlige angreb i stilling. Hvis alle taler om pengene, så er der nok nogen, der gennemskuer mailen og forhåbentlig alarmerer it, som så forhåbentlig kan finde ud af at reagere hurtigt.
Formålet er jo ikke at få folk til at falde i fælden. Det er en misforståelse. Formålet er at øge medarbejdernes bevidsthed om phishing.
Dine succeskriterier er ikke om folk klikker. Succeskriteriet er i stedet, om folk fx rapporterer mailen, så den kan blokeres, og dem der uundgåeligt har klikket kan hjælpes og et angreb stoppes i tide.
Derudover har man som red team nogle etiske forpligtelser. Det er en øvelse, så det er alligevel ikke realistisk, for du har en anden viden om målet og en anden motivation for at angribe. Så derfor er de etiske forpligtelser ikke et stort benspænd jævnfør ovenstående mål og succeskriterie.
Etisk bør personlig sikkerhed, sundhed, privatliv (og herunder personlig økonomi) og ansættelsesforhold være no go for en phishing-test.
Sat på spidsen, så kan du altid lave en mail, der vil presse en person. Er et link til en (falsk) nyhed om et skoleskyderi på dine børns skole ok? Uden klare afgrænsninger kan man nemt komme way uden for scope. Og stå med ubrugelige data fra sin test. Og en kunde, der helst vil fraskrive sig ansvaret.
Hvis man læser deres paper (og som jeg også havde hørt det refereret), så virker det ganske forsvarligt udført - og som et relevant eksperiment.
Der er ikke tale om commits direkte til kernel-rep, men derimod forslag til patches, der blev sendt til en mailing-liste. Hvis forslagene blev accepteret, så blev der taget kontakt til maintainerne om fejlene, og den korrekte fejlrettelse blev indsendt.
Den korrekte reaktion ville være at se på, om man kunne beskytte patch-processen mod denne type angreb (hvor en række små og hver for sig tilsyneladende uskyldige fejlrettelser kædes sammen til at skabe et sikkerhedshul). Hvis nogle forskere på et universitet kan gøre det, hvem kan så ellers?
Men man har selvfølgelig ramt de pågældende maintainers et sted, hvor det gør ondt på deres profesionnel ego. I forhold til, hvad man ellers lader sikkerhedsfolk slippe af sted med ved pentest (f.eks. phishing-tests med emner, der vedrører folks personlige sikkerhed, økonomi eller sundhed), så er det umiddelbart i den milde ende. Burde man have sikret sig, at forsøgspersonerne var indforstået med forsøget. Ja, det burde man nok.
Det her vil være en god case.
Dels er det interessant at finde årsagen (ikke for at placere et ansvar - for det vil næsten altid ligge hos ledelsen), og dels vil løsningerne være nogle, som alle kan lære af.
Det gælder uanset, om årsagen er "Bjarne skulle først have splittet strengen, dernæst parset integeren" eller "Leverandøren gemmer CPR i et uhensigtsmæssigt format".
I begge tilfælde vil løsningen være systematisk: Skal Bjarnes batch-script i fremtiden lige tjekkes en gang, inden det sættes til at spytte mails ud? Skal vi stille mere specifikke krav til dataformater?
Ofte vil det - fra andre havarikommissioner - være flere faktorer og derfor også flere løsninger, der skal i spil.
Udfordringen vil nok altid være, at det i sidste ende lander på "ledelsen skulle nok have interesseret sig lidt mere for, hvad der foregår nede i maskinstuen, men ikke så meget, at de slet ikke kan få noget fra hånden".
Hånden på hjertet: Hvornår har du sidst optimeret en algoritme, altså sådan bevæbnet med matematikken at gå helt ned i de hårde bits - og ikke bare justeret på en parameter i et framework eller ryddet op i en lidt uhensigtsmæssig rækkefølge af operationer i en løkke?
Min påstand er, at det meste af det, vi som flertal i "it-faget" laver, ikke er specielt teknisk. I hvert fald ikke set fra andre fags perspektiv. Lad mig uddybe:
Programmering, selv af ret komplekse programmer, er ikke mere teknisk, end at rigtig mange inden for såkaldt bløde fag som psykologi, biologi, økonomi, medicin og sociologi programmerer i f.eks. R. Ofte med en del mere matematik, end de fleste dataloger har brugt siden studiet.
Ja, der er nogle it-folk, som arbejder med maskinnær programmering eller arbejder med maskine-til-maskine-kommunikation, som virkelig skal kunne de mere støvede lærebøger. Men rigtig meget af programmørtiden i branchen går med at rette vores egne eller andres små fejl i koden. Eller med at diskutere bløde ting som arkitektur i forhold til forretningsprocesser og organisationelle behov.
Eller sidstnævnte burde vi være bedre til. Men vi har en tendens til at underkende, at sådan noget med at forstå, hvordan en organisation fungerer, eller hvordan et menneske arbejder, har stor indflydelse på design af software. Og vi undervurderer måske også, hvor kompleks videnskaben bag organisationsteori kan være.
Programmering er et værktøj. Det er nogle størrelsesordner mere komplekst end en hammer, men dog også nogle størrelsesordner mindre komplekst end meget fysik, matematik eller sociologi.
Så det, jeg prøver at sige er, at ja, der er brug for eksperter inden for vores felt, men vi må også indse, at vi mangler nogle flere, der er gode nok til systemudvikling og programmering, men ikke er eksperter i datalogi, og som til gengæld kan bidrage med ekspertviden fra andre fag.
Om ikke andet, så er denne ekspertviden nok nødvendig, hvis vi vil have en chance for at undgå mange af de fejltagelser i softwareprojekter, som vi igen og igen bliver ved med at påpege - og har gjort det nogenlunde siden 1970'erne, som sjovt nok var cirka deromkring, hvor det med computere begyndte at blive en mandeting.
Ligesom mænd i debatten kritiserer kvinderne for at mangle interesse for programmering og andre tekniske fag, så må vi nok også erkende, at vi står med nogle problemer, som vi ikke har fået til at forsvinde. Og som måske skyldes, at vi selv mangler interesse i nogle andre fagområder.
It-faget har mange facetter. Derfor er der heller ikke kun én indgang til det. Det burde især vi, der er fra generationen med en stor andel af selvlærte og halvstuderede, da kunne anerkende. Derfor kunne vi måske også overveje, om vi burde være mere imødekommende over dem, der har en kandidatgrad i filosofi og historie i stedet for at være civilingeniør i informationsteknologi. Nogle gange kommer interessen for det tekniske først senere i livet, når man har fundet ud af, at det måske er noget, man har talent for - eller er blevet motiveret til at yde et praktisk bidrag til at forbedre de tekniske løsninger, der både kan frustrere og begejstre os alle.
Problemet er jo desværre, at der blot skal et enkelt halvråddent æble til for at gøre en arbejdsplads utryg.
Det skyldes ikke den konkrete arbejdsplads eller branchen som helhed, men mere det, at det i samfundet generelt er forbundet med større risiko at være kvinde. Der er flere trusler, og gentagne undersøgelser indikerer, at en stor andel af kvinder i den vestlige verden oplever dem hyppigt nok til, at det påvirker deres adfærd.
Det betyder, at en arbejdsplads kan være tryg nok med en sund atmosfære, men der skal blot et enkelt indvid til, som udsender de faresignaler, kvinder desværre er oplært til at reagere på, og så bliver arbejdspladsen utryg.
Det kan være adfærd, der ikke umiddelbart observeres som upassende. For eksempel kunne det være en mellemleder, der siger et eller andet henkastet i stil med "... den ramte vi lige i røven. Hov, det må jeg vist ikke sige i disse Metoo-tider, hø hø". For de fleste et helt uskyldigt udsagn. Men det antyder samtidig en legitimering af en kultur, hvor Metoo er noget, der ikke tages alvorligt, men i stedet er noget, vi kan grine lidt over, hvor nærtagende folk er blevet og svenske tilstande og vis nu lidt frisind.
Men for den ene kvinde i forsamlingen kan udsagnet betyde, at hun pludselig bliver nødt til at betvivle, hvor sikker hun kan være på at blive lyttet til, hvis der skulle opstå en mere alvorlig situation.
Det er en megasvær problemstilling, fordi problemerne er usynlige for mange af os. Hvis man læser beretningerne fra Metoo og de øvrige hashtags, så kan man få lidt forståelse for, hvorfor umiddelbart harmløs adfærd kan virke supernederen. Ofte simpelthen fordi det er en adfærd, kvinder oplever hele tiden, eller fordi den minder om noget, der fører til en farlig situation.
Escape character med backslash burde virke. |0|
Det er korrekt for Bitcoin specifikt, men eksempelvis Ethereum benytter en anden hashfunktion, som ikke er kompatibelt med de chips, der er udviklet specielt til Bitcoin-mining. Algoritmen bag Ethereum er også designet til at gøre det vanskeligt at designe specialiserede chips (ASIC). Derimod er den velegnet til mining med GPU'er.
https://99bitcoins.com/guide-ethereum-mining-how-to-mine-ethereum/
Ser man på, hvad folk bruger, så er det da også setups med op til 6 GPU'er:
https://www.reddit.com/r/EtherMining/
Mvh. Jesper/Version2
Andre har tænkt samme tanke:
http://i.imgur.com/NkMs0Gs.jpg
https://twitter.com/CORSAIR/status/884513025159385088
:)
Nu tager den slags tid (og vi kunne også diskutere visse af dem, vi ser i dag, hvorvidt de fungerer som forbilleder) - så måske ser vi en effekt om nogle år (og det vil jo være fint).
Lige med Sato, så forudsætter det, at man ser en genre, som også først for nylig har fået plads i mere mainstream-kultur (jeg kendte hende for eksempel ikke, for Dr. Who er ikke lige noget, jeg har kunnet komme i gang med). Men det er en anden diskussion. Som sagt kan der komme en effekt over tid, men medieafbildningen i 80'erne, 90'erne og store dele af 00'erne har været ret ensidig (Og ja, Hackers - men der er det svært at identificere sig med nogen af hovedpersonerne).
Men her afspejler det også lige netop, at der i den periode skete et skift i den populære fremstilling af fagene. Vi fik tv-serier med kvindelige advokater og læger, og samtidig var disse fag i fokus for ligestillingskampen (fordi det var fag, der er tæt knyttet til magten i samfundet). Det var ikke tilfældet for datalogi.
Der er dem, der peger på mikrocomputerkulturen i begyndelsen af 1980'erne som årsagen, fordi det var en drengeklub. Det var der sådan set ikke noget galt i - men der opstod bare aldrig et tilsvarende rum for pigerne. Det førte til, at det med computere blev opfattet som en drengeting, og senere udviklede det sig til en 'nørdeting' - og det er først for nylig, at det er blevet accepteret, at piger melder sig ind i nørdeklubben (til en vis grad af nørderne, men i lige så høj grad af samfundet i almindelighed, som har knyttet en række negative associationer til de aktiviteter, nørder beskæftiger sig med - jeg møder stadig jævnaldrende og ældre, som siger 'nå, du spiller stadig det der rollespil?' - forstået som, at det er en aktivitet, der hører puberteten til i deres verdensbillede).
Så for Gerda er der flere tærskler, som få af dem, hun direkte kan identificere sig med, har trådt over før hende: Hun skal have tændt den første interesse for programmering, hun skal kunne se sig selv i en karriere som programmør, hun skal kunne fortælle sine omgivelser, at det er det hun vil, og endelig skal hun træde ind på studiet.
Bjarne skal selvfølgelig krydse de samme tærskler, men der er rigtig mange Bjarne'r, som har gjort det før ham - og Bjarne har set dem på film og tv eller mødt dem i virkeligheden.
Det siges måske lidt mere præcist i dette citat fra artiklen på Videnskab.dk:
"Piger går uden om uddannelserne, fordi de kan have svært ved at identificere sig med det køn og den type mennesker, datalogi bliver forbundet med. "
Inden nogen får deres Red Bull galt i halsen, så er det vigtigt at forstå, at der her tales ud fra en sociologisk vinkel.
Det kan helt grundlæggende forklares som, at vi gerne vil passe ind. Hvis du træder ind i DIKU's kantine på din første dag og ikke ser nogen, der ligner dig, så har du svært ved at føle, at du passer ind. Det gælder også, hvis du træder ind i bridgeklubben, milliardærklubben eller strikkeklubben.
Pointen er så her, at den måde it-faget fremstilles på, er stort set rent maskulint (og endda en helt bestemt delmængde - hættetrøjer, pizza og social akavethed). Derfor forestiller de fleste sig - heriblandt også pigerne - at it-faget er forbundet med denne identitet, og hvis man ikke kan se sig selv spejlet i den identitet, så leder man andre steder.
Så dét, forskerne prøver at sige, er (se min level 12 mansplaining), at it-faget skal præsenteres mere inkluderende for de grupper, man gerne vil have bedre fat i. Det gælder sådan set også de drenge, som ikke opfatter sig selv som 'nørder'.
Og så længe folk, der programmerer eller hacker på film næsten altid er nørdede mænd eller urealistisk sexede kvinder, som det kan være svært at spejle sig i, når man skal udfylde den Koordinerede Tilmelding, så vil det være givtigt for it-branchen at kompensere.
Derfor kan det give god mening at sørge for eksempelvis at have en helt lige kønslig fordeling blandt talere til it-konferencer, selvom det måske ikke afspejler, hvordan fordelingen er lige nu, men fordi det kan være et lille signal, der måske kan trække i den anden retning end mediernes stereotyper.
Udfordringen er selvfølgelig, at der på den ene side er denne diskussion om, at 'vi mangler flere programmører' - og på den anden side ved mange programmører godt, at mange it-arbejdsgivere ikke kun kigger mod Indien og Ukraine, fordi udbuddet er større, men også fordi prisen er lavere. Og så er det klart, at det klinger falsk med tiltag for at få flere til at arbejde med it.
(Og så kan det også være let at opfatte det som en kritik af ens egen identitet, når nogen siger, at der er for mange af dem, der ligner dig, og ikke nok af dem, der ikke ligner dig - men det er det ikke. Det er stadig dig som dig - og så også med plads til Gerda, hvis hun har lysten og evnerne)
Hej
Som PHK så rigtigt skriver, så er der flere gode beskrivelser (efterhånden har eksperterne fået pillet koden fra hinanden og er nået frem til en vis konsensus).
Der foregår to krypteringer: Først krypteres filer af bestemte typer. Det sker med helt almindelige brugerrettigheder (som det ville på ethvert system). Dernæst forsøger malwaren at få admin-credentials. Hvis det lykkes, så går den videre til næste omgang.
Men den første kryptering efterlader sin egen ransom-note, som i modsætning til den, der vises efter genstarten faktisk indeholder den rigtige krypterede nøgle (og denne del af dekrypteringen ser ud til at kunne fungere).
https://labsblog.f-secure.com/2017/06/29/petya-i-want-to-believe/
Anden runde kommer ved en genstart (efter 10-60 minutter). Den bruger admin-rettigheder til at overskrive MBR. Ved opstart krypterer den filtabellen, og her gemmer den så ikke den rigtige nøgle til den Salsa-kryptering, som bruges.
https://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-lost-salsa20-key/
Mvh. Jesper
</p>
<p>Kan det tænkes at bagmanden bare er inkompetent?
Errata Security tænker lidt i samme retning:
http://blog.erratasec.com/2017/06/nonpetya-no-evidence-it-was-smokescreen.html#.WVX7dLpuKUk
tl;dr: Ja, malware-bagmænd laver slamkode hele tiden. Jo, Ukraine blev hårdest ramt, men det er ikke bevis for, at det er et statsligt angreb.
Og der står endnu flere detaljer om, at der faktisk er to niveauer af kryptering her til sidst i denne analyse fra F-Secure:
https://labsblog.f-secure.com/2017/06/29/petya-i-want-to-believe/
(analysen har også nogle interessante overvejelser i forhold til tilblivelsen af malwaren)
Og lidt mere information om krypteringen:
https://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-lost-salsa20-key/
Hej Thomas
Det seneste, jeg kunne finde frem til, er, at der er lidt usikkerhed om, hvorvidt overskrivningen af MBR på pc'en er fatal (og potentielt forhindrer dig i at mounte disken). Men ja, i princippet skal man blot bruge bagmændenes private nøgle til at få låst op for den nøgle, filerne er krypteret med. Der har været eksempler på, at ransomware-grupper har frigivet deres nøgle:
Malwareanalytiker @hasherezade fra Malwarebytes siger, at der slet ikke gøres noget forsøg på at gemme koden. I forhold til den oprindelige Petya, hvor ID'et var den krypterede nøgle, så er det her ændret til bare at være noget tilfældigt.
https://twitter.com/hasherezade/status/880404347917672449
Altså skulle inkompetencen bestå i at fjerne noget kode og erstatte det med noget, som gjorde noget helt andet end originalen. Ikke umuligt, men i så fald meget underligt.
Jesper Stein Sandal