Det er slut med McAfee – i hvert fald som produktnavn for antivirus. Intel vil nemlig skrotte navnet og i stedet lade det røde skjold være baggrund for navnet Intel Security. Det var en af meldingerne fra Intel på første dag af CES-messen i Las Vegas, rapporterer britiske BBC.

Dermed forsvinder en af verdens mest kendte antivirus-brands, og isoleret set virker det spøjst, at Intel smider den del af opkøbet ud. McAfee blev købt af Intel i 2010 for 42 milliarder kroner, hvilket var 60 procent over markedsprisen.

Men omvendt har navnet McAfee de senere år ikke kun været i medierne som et kendt antivirusfirma, men i høj grad også med kulørte historier om stiferen af firmaet, John McAfee, som forlod McAfee-firmaet for tyve år siden med masser af penge på lommen.

Og han har mildt sagt ikke været loyal over for det firma, han skabte, i sine udmeldinger de seneste år. Hans reaktion på, at Intel dropper McAfee-navnet, lød ifølge BBC således:

»Jeg er for evigt Intel taknemmelig for at løsrive mig fra den forfærdelige association med den værste software på jord. Det er ikke mine ord, men ordene fra millioner af irriterede brugere,« sagde John McAfee.

For godt et år siden skrev it-medier verden rundt om John McAfees flugt fra politiet i Belize, som han ikke stolede på, efter hans hjem i det mellemamerikanske land tidligere var blevet udpeget som narkorede og stormet af specialpoliti. Da naboen blev myrdet, valgte han at flygte, da politiet dukkede op på hans grund.

John McAfee har også i 2013 gjort sig den ulejlighed at producere en nøje iscenesat video, hvor han sviner McAfee-softwaren til.

Jeg har altid rodet meget med software versionskontrolsystemer, og for tiden er det Git jeg bruger tid på.
En af de ting med Git jeg ikke har set en god løsning på er håndtering af afhængigheder mellem Git-projekter.
Derfor vil jeg gerne høre jeres erfaring.

Ofte laver jeg forskellige programmerings-projekter, som afhænger af de samme grundfunktioner. Jeg nægter at starte de enkelte projekter med at kopiere grundfunktionerne ind.
Det er mere oplagt at strukturere min kode, så grundfunktioner samles i et eller flere Git-repositories, som så skal checkes ud sammen de egentlige projekter. Det giver langt bedre kontrol
med koden, og skal jeg tilføje flere grundfunktioner eller rette fejl, så er der kun et sted jeg gør det.

Min lomme-research (ca på niveau med den fineste forskning på området host) viser at der er mindst fire forskellige måder at håndtere dette på

• Git submodules (http://git-scm.com/book/en/Git-Tools-Submodules)
• Git subtree (https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt)
• Google Git-Repo (https://code.google.com/p/git-repo/)
• Se de forskellige projekter som uafhængige projekter, der “bare” clones en efter en, så de f.eks. ender som kataloger ved siden af hinanden. Denne løsning er jeg ikke glad for fordi jeg kun manuelt kan binde versionerne mellem projekterne sammen.

Det jeg har set er, at Git submodule er “ok”, men ifølge dokumentationen er der flere begrænsninger der:

• Afhænger Git-projektet Top.git af Sub.git så bliver den version af Sub,git man importerer (med git submodule add) ind også reelt den man fortsætter med. Jeg kan opgradere, men det er ikke “bare lige”.
  Egentlig kan jeg godt lide dette, men jeg vil gerne fra start bestemmer om underprojekter skal opdateres løbende mod en master-branch i underprojektets git-repository eller ej.
• Jeg kan vist ikke klone mine hoved projekter f.eks. “Top.git” og automatisk få “Sub.git” ind. Det kræver at jeg efterfølgende kører “git submodule init” og “git submodule update”. Det er lidt kluntet.
• “Sub.git” skal altid checkes ud inde i mine projekter. Det vil i nogle sammenhænge være smart hvis jeg f.eks. kunne checke “Sub.git” ud parallelt med “Top.git”.

Git subtree og Git-Repo har jeg ikke nået et se på endnu

Jeg vil meget gerne høre jeres erfaringer med dem alle, og også om jeg har overset noget her.

/pto

Når du har læst dette blogindlæg, har du fået indblik i mit syn på sikring af organisations- og forretningsudvikling i moderne organisationer gennem agil forretningsudvikling.

”A potential shippable product” er outcomet af ét ”sprints” udvikling i alle agile projekter (iflg. SCRUM-terminologien). ”A potential shippable produkt” dækker over leverancen af et produkt, en brugbar del af et produkt, en procesforbedring, en ny funktionalitet, fjernet en besværlig arbejdsproces etc., som kan tages i brug efter release. Ved hele tiden at skubbe brugbar nyudvikling og eventuelle ændringer og tilpasninger igennem et sprint, sørger man for kontinuerligt at skabe værdi i forretningen og organisationen, som hele tiden bliver klogere og mere konkurrencedygtig. I min optik er det ikke blot agil udvikling – men agil forretningsudvikling. Og det er grunden til, at jeg altid vil stemme for at udviklingsprojekter i moderne virksomheder skal gribes an som agile projekter.

Hvordan griber man det så an i praksis – og hvad er det vigtige i en sådan proces?

Man begynder med at afgrænse et produkt, et forretningsområde eller et andet udvalgt område, hvor man ønsker at skabe udvikling. Dernæst udpeger man en person (en forretningsejer/product owner) som har ansvaret for at sikre den højest mulige værdi for alle stakeholders samt, ikke mindst, er en der har indsigt i hvad der ønskes udviklet. Denne person udarbejder en backlog af ønsker, som alle har et formål og kan beskrives som et ”Potential shippable product”.

Til udvikling og implementering af disse ønsker skal man sikre sig et committed team, der indeholder alle de fornødne kompetencer til at udvikle forretningsejerens ”potential shipable product”. Det ville fx i en it-udviklingskontekst betyde kompetencer fra arkitektur til implementering.

Når teamet er på plads, er det tid til at planlægge et sprint. Først besluttes længden på sprintet, og herefter opprioriterer forretningsejeren de opgaver i backloggen, der vil give mest værdi til forretningen/produktet. På et sprint-planlægningsmøde beslutter forretningsejeren og teamet, hvor mange af disse opgaver man kan nå at udvikle og implementere i det valgte tidsrum – og derefter går udviklingsprocessen i gang. En proces, hvor forretningen/organisationen ved sprintets afslutning har udviklet de produkter, processer, tilpasninger (shippable products) etc., som forventes at give størst værdi for forretningen – hvilket i min optik er kernen i agil forretningsudvikling.

Hvis denne proces gentages igen og igen i mange iterationer vil man hele tiden tilføje værdi til organisationen og forretningen. Man prioriterer hele tiden, hvad der i en given situation vil kunne give mest værdi, og man sikrer hele tiden, at man tilpasser den agile udviklingsproces til netop den situation man befinder sig i på det givne tidspunkt.

Kun ved hele tiden at fokusere på formålet med al udvikling, prioritere det imellem andre ønsker og sikre korrekt og brugbar implementering, styrker man forretningen/organisationen og gør den mere konkurrencedygtig. Derfor er agil forretningsudvikling måden at opnå den største værdiskabelse på i en foranderlig verden.

Jeg håber, at disse tanker kan være brugbare for dig, når du og din organisation står over for jeres næste projekter. Og jeg håber ligeledes, at det kan sætte gang i en debat om, hvordan I sikrer den optimale udvikling internt i jeres organisation.

En gennemgang af sikkerheden hos CSC afdækker, at it-leverandøren tilbage i 2012 var tre måneder om at lappe et alvorligt sikkerhedshul i mainframesoftwaren, selvom leverandøren IBM havde udsendt to opdateringer markeret som kritiske. Det fremgår af materiale, som Version2 har fået aktindsigt i.

Materialet er en sikkerhedsrevisionsrapport udarbejdet af Deloitte for Rigspolitiet, der gennemgår de generelle it-kontroller, som CSC skal overholde i kraft af den databehandleraftale, virksomheden har indgået med myndigheden.

Under kontrollen af CSC’s ‘styring af tekniske sårbarheder’ opdagede Deloitte, at it-leverandøren ikke havde ordentlig styr på proceduren for at installere sikkerhedsopdateringer, såkaldt patch management.

»Vi har konstateret et stort antal kritiske sårbarheder som følge af manglende patching af VMware (lukket marts 2013),« fremgår det af rapporten.

VMware er software til at køre virtuelle maskiner i datacentre.

Overså kritiske opdateringer

I en uafhængig rapport udarbejdet af Center for Cybersikkerhed, og som Version2 ligeledes har fået indsigt i, fremgår det, at IBM den 21. december 2012 udsendte to patches, der var markeret som kritiske. Alligevel opdagede CSC først tre måneder senere, at den var gal.

»4. marts 2013: CSC bliver opmærksom på, at patches udsendt i december af IBM, som CSC på dette tidspunkt endnu ikke har implementeret, udbedrer en væsentlig sårbarhed i mainframesoftwaren,« lyder det i rapporten fra Center for Cybersikkerhed.

Sideløbende havde dansk politi også overset en advarsel fra svensk politi, der i en efterforskning af et svensk hacker-angreb havde fundet tegn på, at også danske registre, der lå hos CSC, kunne være blevet kompromitteret. Derfor var det først i slutningen af februar, at CSC blev indkaldt til et møde hos Rigspolitiet, der gjorde dem opmærksomme på hacker-angrebet.

Kort efter, i starten af marts, opdagede CSC de manglende patches.

CSC ser uprofessionel ud

Version2 har forelagt revisionsrapporten for professor på DTU Compute Lars Ramkilde Knudsen, der er ekspert i it-sikkerhed og blandt andet har været med til at tilrettelægge et nyt uddannelsesforløb i Computer Security på DTU. Han synes, CSC ser uprofessionel ud.

»Det ser ikke godt ud. Der fremgår ligefrem, at der er tale om et stort antal kritiske sårbarheder. Det er jo problematisk. Det virker lidt mærkeligt, at de ikke har patchet med det samme. Det har man svært ved at forstå,« siger Lars Ramkilde Knudsen til Version2.

Ud over patching-fejlen fandt Deloitte yderligere ét kritisabelt forhold blandt de 33 gennemgåede områder. Under kontrolpunktet for ‘styring af adgang til driftssystemer’ står der:

»Vi har konstateret, at der foretages service console-login på en VMware-host direkte med root (lukket december 2012).«

I resten af rapporten finder Deloitte ingen grund til anmærkninger hos CSC.

Hvor meget skal man så lægge i denne her fejl?

»En kæde er aldrig stærkere end det svageste led. Der skal jo helst ikke være fejl nogen steder, så det er da et problem. Jeg ville i hvert fald være meget bekymret, hvis jeg var it-chef og modtog sådan en rapport,« siger Lars Ramkilde Knudsen til Version2.

CSC har ikke ønsket at kommentere historien.

Læs hele revisionsrapporten her