Dette indlæg er alene udtryk for skribentens egen holdning.

CSRB's opus 1

3 kommentarer.  Hop til debatten
Blogindlæg14. juli kl. 21:00
errorÆldre end 30 dage

Som direkte følge af Colonial Pipeline fiaskoen, nedsatte Præsident Biden en IT-Havarikommision, med direkte henvisning til de tilsvarende HK'er USA allerede havde.

Nu er deres "opus 1" udkommet og den handler om log4j:

https://www.cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf

Jeg havde egentlig forventet at Colonial Pipeline ville blive deres første udgivelse, men Biden ikke gav dem bagudvirkende beføjelser.

Artiklen fortsætter efter annoncen

Log4j var ikke ligefrem en trillebold, tværtimod, den skruede i så mange forskellige retninger at den kommer tæt på et "worst-case" scenarie.

Det er en god første rapport og som rapporter fra USA nu engang gør, vælter kaster den rundt med forkortelser, inklusive et par nye de opfinder undervejs.

Rapporten afslører på side 15 (pdf side 23) hvor kort der var til "worst case":

Den første advarsel kommer fra Alibaba's Cloud organisation i Kina til Apache Software Foundation d. 24 november, men først d. 13 december informeres Det kinesiske  "Ministry of Industry and Information Technology"[1], selv om loven i Kina siger det skal ske efter to dage.

Hvis ministeriet var blevet advaret først og hvis de havde valgt at mørklægge sagen, havde Kinas efterretningsvæsen haft fri skydning i det muntre køkken i måneds- hvis ikke ligefrem årevis.

Der er ét aspekt jeg personligt synes de kommer for let hen over, men jeg indrømmer blankt at jeg her er farvet af min egen rolle i FOSS projekter:

Log4j software featuren gjorde præcis hvad den var designet til og burde (formodentlig) derfor aldrig være designet (således).

Men tro mig, et bare nogenlunde kompetent og brugbart stykke FOSS software vil blive brugt på måder, eller i et omfang, forfatterne slet ikke havde fantasi til at forestille sig.

Men hvis forfatterne ikke kan forestille sig hvorledes softwaren bliver eller vil blive brugt, hvordan skal de så kunne tage kompetente fremtidssikre designbeslutninger ?

Der vælter en masse skeletter ud af netop det skab: Hvem tager i praksis designbeslutninger ? Bliver de dokumenteret ? Bliver baggrunden for beslutningen også dokumenteret ?  Er der nogen der læser denne dokumentation ?  Bliver beslutningerne regelmæssigt  taget op til revision ? osv.

For så vidt anbefalingerne kan man derfor godt komme til at tænke på en tidl. statsminister der spurgte "Kan vi ikke allesammen gøre det lidt bedre ?" for der god plads til forbedringer, hele vejen rundt.

Den onde ånd i flasken er naturligvis den sædvanlige:

Dependency
Illustration: XKCD.COM.

(Det ærgrer mig faktisk at CSRB ikke havde modet til at inkludere en link, det ville have været et fantastisk "easter-egg" i en fodnote.)

Under overskriften "Build A Better Software EcoSystem" kommer der et antal gode og fornuftive anbefalinger, herunder anbefaling 13 om at USA regering, i sin rolle af "significant consumer and producer of open source software" burde tage sit eget ansvar meget mere seriøst og hive muldvarpeskindet op:

  • OMB should take appropriate steps to direct federal agency IT staff to contribute to the security and maintenance of open source software upon which they rely, as part of their regular duties.
     
  • ONCD, in coordination with OMB, should consider effective funding mechanisms to invest in widely used open source software tools, and to catalyze improvements in the overall security of the open source software ecosystem.

(OMB ~ Finansministeriet, ONCD ~ Civil udgave af CfCS.)

Det første punkt er nok det mest fremkommelige, gør forbedring af sikkerheden til en del af arbejdsopgaven for de IT-folk der ruller FOSS softwaren ud i statsadministrationen[2].

Det andet punkt vil være noget vanskeligere at få søsat, for så snart der kommer penge på bordet flokkes gribbene.

Hvis det var mig der skulle lave et udkast til ONCD, ville jeg foreslå en slags "McArthur-Grants":

Hver måned udvælges der er ét ungt talent der ser ud til at være værd at satse på.  Ikke på basis af hvad de allerede har gjort, men på forventet efterbevilling.  Disse udvalgte modtager i fem år $10000/måned til at gøre lige hvad netop de synes der kan og bør gøres for at forbedre FOSS.

Men alt i alt, en god start fra USA's IT Havarikommission.

Hvornår får vi en i Danmark ?!

phk

[1] HVAD?! Er det lovligt for et land sådan bare uden videre at have et Ministerium for IT ?!

[2] Et problem vi heldigvis ikke har her i landet, hvor alting skal være Microsoft.

 

 

 

3 kommentarer.  Hop til debatten
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
3
23. juli kl. 16:17

Uanset set om man taler om FOSS eller closed source, kan man hurtigt stå med håret i postkassen, hvis man ikke holder øje med, om delkomponenter har en brist eller - som i dette (https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.rijndael?view=net-6.0) tilfælde - bliver forældede eller ikke længere vedligeholdes.

Som programmør el. softwarehus, kan man godt tænke, at det er produktejerens eget ansvar - og som køber af et stykke software, tænker man, at programmøren / sælgeren, har helt styr på det og siger til, hvis noget skal opdateres. Så længe der ikke er regler, falder ansvaret let mellem to stole.

Hvem der har ansvaret for det og hvornår, bør der altså laves retningslinjer for. Men begge parter bør have fokus på det, for et softwarehus kan gå fallit og en programmør kan blive kørt over af en bus - og hvem har så ansvaret for, at et eller andet stykke kode fra Github eller en komponent i .NET stadig er sikkert at bruge?

Som producent skal man kunne fortælle, hvilke komponenter - om det så er fra Github, .NET eller noget helt tredje - der er blevet brugt, således at man som kunde selv kan holde øje, i fald producenten skulle gå fallit. Slutbrugere som gamle fru Hansen er selvfølgelig undtaget.

Som slutbruger, der ikke har nogen indflydelse på teknikken, bør man give sin smartphone et klap af en hammer, så snart den ikke længere får opdateringer. Som sælger af smartphones eller hvilket som helst andet elektronik, bør man give sine kunder besked, så snart det ikke længere kan opdateres - eller om det skal opdateres. Og som producent bør man give både kunder og forhandlere besked. Dette bør der være regler for, og når de regler er der, kan man afgøre, om nogen har svigtet, hvis noget software viser sig at have en brist.

Just my two cents - her mit i ferien :-)

2
18. juli kl. 14:00

Genial tegning, mangler bare nogle flere af de der Nebraska projekter, og så det der projekt, som nogle studerende lavede i 1998, og som ingen har tænkt over siden, fordi det ikke har vist svaghedstegn endnu.

1
15. juli kl. 11:31

Tak for godt indlæg