It-säkerhet enligt HPS

Stefan Pettersson på High Performance Systems skriver om säkerhet på svenska

Sophos: security features != secure features

The paper includes a working pre-authentication remote root exploit that requires zero-intera[c]tion, and could be wormed within the next few days. I would suggest administrators deploying Sophos products study my results urgently, and implement the recommendations.

Så inleds den andra delen av Tavis Ormandys Sophail-rapport som släpptes på Full-Disclosure i måndags. Det är en kuslig påminnelse att det är skillnad på säkerhetskomponenter och säkra komponenter.

Mitt examensarbete på skolan behandlade i viss utsträckning generiska skydd mot buffer overflows: till exempel stack canaries, NX/XD och ASLR. CJ, som var min handledare, och jag var då och träffade en återförsäljare av just Sophos i hopp om att få lite mer information om hur deras BOPS-teknik fungerade. BOPS, eller Buffer Overflow Protection System, skulle alltså vara ytterligare ett sådant generiskt skydd.

Lång historia kort, vi blev besvikna. Den ”expert” som vi fick prata med förklarade att man kunde sätta på BOPS för enskilda binärer eller globalt och sedan vitlista vissa binärer. Hur BOPS verkligen gjorde för att stoppa attacker hade han ingen aning om. Wow.

Överraskande nog har BOPS precis motsatt(!) effekt, avsikten är att införa något som liknar ASLR men istället ser den till att det alltid finns en statisk (istället för en slumpmässig) adress i minnet att gå mot. Från Ormandys rapport (min fetstil):

The purpose of BOPS (although it does not work) is to provide a faux-ASLR implementation for Windows XP. Sophos ship the product on other platforms but it is essentially a no-op. Sophos uses AppInit_DLLs to force load this nondynamicbase module into every process, disabling ASLR on platforms that do have it enabled.

This effectively disables ASLR on all Microsoft Windows platforms that have Sophos installed, allowing attackers to develop reliable exploits for what might otherwise have been safe systems

Christoffer var snabbare att dra parallellen till Kerckhoff och hans hundra år gamla princip.

Ormandy ger tre råd till de drabbade:

  1. Förbered er på att stänga av Sophos AV på alla system (om en mask skulle dyka upp).
  2. Installera inte Sophos-produkter på kritiska system, det finns helt enkelt för många sårbarheter.
  3. Installera inte Sophos-produkter på system som är svåra att uppdatera, det finns helt enkelt för stort behov att hålla produkten uppdaterad.

Det är ett obehagligt problem att programvara som utvecklas och distribueras brett ibland är i dåligt skick. Det är sånt som gör skadeansvar till ett intressant ämne.

Hacka lönedatabasen

Den som […] olovligen bereder sig tillgång till en uppgift som är avsedd för automatiserad behandling eller olovligen ändrar, utplånar, blockerar eller i register för in en sådan uppgift döms för dataintrång till böter eller fängelse i högst två år.

Så beskrivs ”hacking” av 4 kap. 9c § Brottsbalken. Den är en gammal sanning att poliser och sjukhuspersonal är överrepresenterade i brottsstatistiken över dataintrång. Det är dock inte för att de är särskitl l33t utan bara för att de har legitim tillgång till register över patienter och kriminella och bara får ta del av uppgifter som rör sina egna ärenden. Det är t ex många läkare som har tillgång till Micke Persbrandts journal men det är bara hans läkare som får ta del av den.

Det är skillnad på behörighet och befogenhet.

Ingen regel utan undantag dock, en sjuksköterska i Malmö har enligt utsago höjt sin egen lön.

Fråga 1: Hur gick det till? Helt utan belägg gissar jag att hon (ja det är en hon) har använt någons lösenord.

Fråga 2: Hur upptäcktes det? Artikeln säger att det upptäcktes i september 2011 och att intrånget skett någon gång mellan januari och september samma år. Jag gissar att det inte upptäcktes av en säkerhetsavdelning utan av en (1) löneadministratör/revisor, (2) chef eller (3) kollega.

Vi får helt enkelt vänta till att förundersökningens sekretess hävs.

Trevlig helg!

Incidenthantering

I slutet på 80-talet, när internet fortfarande använde pottan, fanns en ung man som hette Robert Morris. Han är känd för att vara skapare av en av de första datormaskarna, program som autonomt sprider sig från dator till dator. Masken i fråga, the Morris Worm eller ibland the Internet Worm, släpptes lös den 2 november 1988 och infekterade UNIX-maskiner genom att utnyttja säkerhetsbuggar i sendmail och fingerd samt trust-förhållanden (rsh) och svaga lösenord.

En betydande del av internet infekterades. På grund av en blunder i designen kunde masken infektera samma dator flera gånger, efter tillräckligt många infektioner kunde inte datorerna klara antalet processer längre och lade av.

Det finns massor av text att plöja om den här erfarenheten: Gene Spaffords analys och RFC 1135 är bra. Det är förresten tråkigt att begreppet helmintiasis som RFC:n använder inte fick fäste. Helmintiasis är nämligen benämningen på ”[i]nfektioner orsakade av rundmaskar (nematodinfektioner) och bandmaskar (cestodinfektioner)”.

Internet var designat för att klara av fysiska angrepp, om en central router slogs ut skulle trafiken routas om automatiskt. Internet var inte bara ett sätt att koppla ihop forskare, internet var själv ett forskningsprojekt inom survivability. Internet var dock inte rustat för masken.

Vad gjorde då DARPA som var ansvarig för internet när det begav sig? Installerade de antivirus-program på alla servrar? Utvecklade de och sålde brandväggar med unified threat management? Startade de ett regulatoriskt organ som gav ut pärmar med obligatoriska säkerhetskrav?

Nej.

När man insåg att man var dåligt förberedd startades Computer Emergency Response Team Coordination Center vanligtvis känt som CERT® Coordination Center.

Man förberedde sig på incidenthantering.

Vad är det fina med den åtgärden? Jo, CERT kunde agera på allt. Det spelade ingen roll om det var en mask eller hackerintrång eller vilken metod masken eller hackern använde. Det var ett generellt skydd, inte heltäckande men generellt.

Varje gång det händer något så är de värdefulla. Det är enkelt att räkna upp hundra situationer då en UTM-brandvägg är fullständigt värdelös men det är svårt att komma på särskilt många relevanta situationer där förberedd incidenthantering är det.

På sätt och vis är en förberedd incidenthanteringsgrupp den ultimata säkerhetsåtgärden. Varför är då min upplevelse att företag investerar tvärt om?

Komplexitet och säkerhet: ett exempel

”Complexity is the worst enemy of security.” -Bruce Schneier

Det känns rätt gammalt att säga att komplexitet och säkerhet är motpoler men inget kunde vara mer sant. Några av mina favoritgubbar Saltzer & Schroeder uttryckte det som: economy of mechanism, slösa inte med mekanismer. Designa system som är små, enkla och funktionsfattiga. Enkla system är enkla att skydda. Christoffer skrev om det här tidigare i år.

Jag tänkte försöka mig på ett tydligt exempel från boken Computer Security: Art and Science av Matt Bishop, en favoritbok.

(Varning utfärdas härmed om att inlägget är lite raljerande…)

Book cover

I ett kapitel (kommer inte ihåg vilket) berättas historien om ett företag som har en webbserver varifrån besökare kan köpa saker på kort. Hur kan detta implementeras på ett säkert sätt? Jag minns inte exakt hur det var men det är inte så noga.

Förslaget som ges i boken är lätt att förklara: Apache-webbservern i DMZ tar emot besökarens data från ett formulär (namn, leveransadress, kortnummer, etc) via CGI (Perl eller Bash kanske) över TLS, validerar uppgifterna och skriver dem till en textfil på disk, krypterar textfilen med en publik nyckel (openssl t ex) och ett cronjob kopierar den till en spooling-katalog dit webbservern inte har åtkomst, originalfilen shreddas.

Med jämna mellanrum anropas webbservern i DMZ av en annan server på det interna nätet, filerna kopieras över SSH, kanske med rsync, originalfiler shreddas. De hämtade filerna dekrypteras med den privata nyckeln, uppgifterna valideras (igen) och lämnas vidare till affärssystemet som löser resten.

Enkelt. En generell säkerhetsspecialist med Unix-erfarenhet skulle kunna implementera det här på en eftermiddag. Samma person skulle kunna få det här förklarat för sig och säkerhetsgranska implementeringen på ett par timmar. Det är lätt att bilda sig en uppfattning om systemets säkerhet.

Person viker ett pappersflygplan

Okej, switch till en ”modern” motsvarighet.

I DMZ står EPiServer .NET Content Management System, den består av massor av DLL:er och XML-filer, kör på IIS. EPiServer kan göra massor av saker, det finns massor av plugins. Om det inte är EPiServer kanske det är ett, men förmodligen flera, större ramverk (och ännu fler XML-filer) på en applikationsserver som kör Java EE. Anywho.

Servern tar emot ett betalningsobjekt som sedan serialiseras och skickas som asynkront meddelande i XML-format kanske via MQ, kanske över TLS till en BizTalk-server på det interna nätverket. BizTalk genomför någon form av transformering på meddelandet och vidarebefordrar det till affärssystemet med ytterligare ett protokoll, synkront med SOAP över http kanske?

Mechanic checking out a jet engine

Nu vet jag inte om det ”moderna” fallet är säkert eller inte. Det är också poängen. Det är svårt, för att inte säga omöjligt, för någon att avgöra. Det är för mycket funktionalitet, för mycket indirection, för stor abstraktion för att kunna skaffa sig en rimlig uppfattning om hur säkert det är. Det är för komplext.

Visst, det moderna fallet ger säkert massor av fördelar: det skalar väl, det finns färdiga API:er för olika affärssystem, det är snabbt, det är möjligt att byta ut olika delar, det finns en leverantör att ställa till svars, allt möjligt. Du kan däremot aldrig hitta en generell säkerhetsspecialist som kan avgöra hur säkert det är.

Hur, exakt, hanterar EPiServer formulärdata? Not a clue. Hur, exakt, förs det vidare till BizTalk? Not a clue. Hur väl, exakt, skyddas vårt ”meddelande” medan det är i BizTalk? Not a clue. Hur, exakt, är det med nästa sträcka mot affärssystemet? Not a clue.

Självklart finns det en person som har benkoll på vad EPiServer gör med de data som användaren lämnar. Självklart finns det någon som kan BizTalk, alla protokoll den stödjer och vad det innebär att uppgifterna transformeras innan överlämningen. Det är dock inte samma person och det är inte alls säkert att någon av dem kan säkerhet.

Så, slutraljerat.

Carl-Johan påpekar att det finns två sorters komplexitet i exemplet ovan: komplexitet i arkitekturen och komplexitet i komponenterna. Båda former är ovälkomna men för en säkerhetsgranskare är komponentkomplexitet värst. Det underlättar inte att komponenterna är stängda; granskaren har väldigt lite att gå på, man använder underliga protokoll, släpper ingen källkod, inga detaljerade arkitekturbeskrivningar utan bara användarmanualer (orgier i skärmdumpar och steg-för-steg-beskrivningar). När det finns information kan den istället vara överväldigande eftersom varje komponent är såpass stor. Jämför EPiServer med Apache eller BizTalk med SSH i det här fallet.

Det enkla alternativet bygger på vedertagna standardprogram, på protokoll som finns beskrivna i RFC:er, det finns program för att undersöka protokollen, Wireshark kan tolka dem, det går att koppla in fuzzers o s v. En säkerhetsgranskare kan göra sitt jobb på kortare tid och med högre kvalitet. Apache-fallet kan jag ge ett kvalificerat yttrande över på en eftermiddag. EPiServer-fallet skulle kräva ytterligare personer, och flera månader men yttrandet skulle ändå vara ganska skakigt.

Men, ha en trevlig helg ändå!

Säkerhetsutbildning och användare

Framsida på tidningen MetroNär Metro publicerade det här på förstasidan om att lära trafikanter att gå i spärrar var det svårt att motstå ett blogginlägg om att utbilda användare i säkerhet, så kallad security awareness training.

Det har ju varit en del bråk om just detta efter sommaren. Det började väl mer eller mindre med att Dave Aitel (Immunity) skrev en artikel för CSO i somras med rubriken Why you shouldn’t train employees for security awareness:

If there’s one myth in the information security field that just won’t die, it’s that an organization’s security posture can be substantially improved by regularly training employees in how not to infect the company.

[…]

Instead of spending time, money and human resources on trying to teach employees to be secure, companies should focus on securing the environment and segmenting the network. It’s a much better corporate IT philosophy that employees should be able to click on any link, open any attachment, without risk of harming the organization. Because they’re going to do so anyway, so you might as well plan for it.

Marcus Ranum uttryckte sig, som vanligt, härligt/syrligt någon gång när han sade något i stil med: ”We have trained users for about a decade now, it hasn’t worked very well”.

Samtidigt, självklart fungerar det att utbilda i säkerhet, om inte så hade Aitel och Ranum orsakat lika många incidenter som vanliga användare. Vilket jag antar att de inte gör.

Det går att lära folk att vara på sin vakt. Det är däremot inget att vila säkerheten på, Aitel är spot on när han skriver att användare behöver kunna klicka på vilken länk som helst, öppna vilken bifogad fil som helst utan att riskera att skada organisationen. De kommer att göra det i alla fall förr eller senare så du kan lika gärna förbereda dig på det.

Försök inte göra det mindre sannolikt att de gör något dumt, se till att det inte spelar så stor roll.

Det är förstås inte svart eller vitt. Det är högre ROI på att utbilda få användare som bryr sig än att försöka utbilda många användare som inte bryr sig. Framgång hänger också på hur ofta användare har användning för sina kunskaper. Ställ dig några frågor:

  1. Bryr de sig om vad jag utbildar i?
  2. Hur många är det som ska utbildas?
  3. Är det något de kommer att ha nytta av ofta?

Chansen att SL skulle ha någon framgång i att utbilda sina trafikanter är med andra ord ganska låg.

Det spelar ingen roll att det i teorin är superenkelt att gå genom en glasspärr: (1) vi vill inte behöva bry oss om hur vi gör, vi vill bara lägga kortet mot läsaren och gå framåt. (2) Dessutom är vi så många att SL får svårt att nå ut och (3) det händer nästan aldrig att man blir klämd, oftast går det alldeles utmärkt att inte tänka sig för.

Jag misstänker att ”användare” har motsvarande syn på bifogade filer.

Är du däremot en liten organisation (färre än tjugo?), har en hotbild och drivna medarbetare kanske det är förmånligare att utbilda dem än att låsa ner miljön och förbereda för incidenter.

Säkerhet och begagnade bilar

Jag behöver av olika anledningar köpa en bil och det kommer att bli en begagnad en. Jag har länge fruktat inför det här, dels för att mina bilrelaterade kunskaper är synnerligen begränsade men framför allt för att jag tror på alla fördomar om bilförsäljare.

Used car sign

De flesta av mina åsikter om begagnade bilar kommer från min favoritekonomiuppsats (om man kan ha något sånt) The Market for Lemons: Quality Uncertainty and the Market Mechanism av George Akerlof. Jag har tydligen nämnt den tidigare på bloggen.

Den handlar i korthet om att marknaden för begagnade bilar tenderar att dra till sig dåliga bilar (lemons) snarare än bra bilar (cherries) eftersom köpare har dåliga förutsättningar för att avgöra bilens skick. Säljare inser att köpare inte kan se att bilen är dålig, marknadsför den som bra, köpare inser detta och börjar utgå från att bilarna är dåliga, säljare av bra bilar låter bli att sälja dem på marknaden för att köpare utgår från att de är dåliga, ond spiral. Bad driving out the good.

Jag känner att jag inte har någon som helst anledning att lita på en bilförsäljare. Det ligger i säljarens intresse att sälja en så dålig bil som möjligt för så högt pris som möjligt. Oftast är bilhandlare dessutom köpare emellanåt så när du ska sälja din bil till dem vill de ge så lite pengar som möjligt för en så bra bil som möjligt.

Det här är ju något som gäller oavsett vad man ska köpa men för mig blir det av någon anledning extra tydligt i samband med bilköp.

Ännu värre blir det när man har ”en bil i inbyte”. Det är lätt att tolka det som att handlaren gör dig en tjänst, är bussig, som tar hand om din gamla häck till bil nu när du ska köpa en finare. Det är ju kanon, handlaren fixar med avställning o s v så att du slipper…

…men nu är du ju både köpare och säljare, handlaren kan lura dig två gånger.

I säkerhetsvärlden är det här ett vanligt problem, två parter som inte litar på varandra. Verisign är i den branschen, Kerberos bygger på det. Enter the trusted third party.

Kvarndammen är ett exempel på en bilhandlare som utnyttjar detta. Man låter en s k värderingsman värdera bilen, utifrån denna värdering sker sedan en auktion. Tanken är att värderingsmannen är oberoende och inte har något incitament att vare sig över- eller undervärdera bilen. Lysande.

Modellen vilar dock på att tredjeparten, värderingsmannen, är pålitlig. Värderingsmannen ska bara vara intresserad av att ge en rättvis bedömning av bilens värde, inget annat. Själv känner jag att jag litar på värderingsmannen, åtminstone i mycket större utsträckning än på godtycklig bilhandlare eller Blocket-försäljare. Jag ska dock erkänna att jag inte har några särskilda belägg för detta förtroende. Jag skulle dock önska att Kvarndammen hjälpte mig på traven lite:

  • Skriv ut namnet på värderingsmannen, utnyttja att hon vill uppehålla sitt goda rykte om rättvisa värderingar.
  • Var tydligare med att värderingsmannen inte har några ekonomiska incitament som gynnar vare sig säljare eller köpare. (Om det nu är så det ligger till, vilket jag verkligen hoppas.) Hon ska t ex absolut inte få procent på försäljningspriset.

Ska man ta det ännu längre kanske det går att skapa en lönemodell som gynnar rättvisa värderingar. Omvänd procent på skillnaden mellan listpris och slutgiltigt pris kanske?

(Nej, det här är inte avsett att vara reklam för Kvarndammen, bara ytterligare en observation av säkerhet i vardagen.)

En annan intressant funktion är hur själva auktionen går till. Vid sluttiden som publiceras för varje objekt börjar en nedräkning på tre och en halv minut, om ett nytt bud läggs under denna nedräkning börjar nedräkningen om. Så fortsätter det till någon har det högsta budet.

Det är ett sätt att undvika s k auction snipers där oärliga typer budar över med en liten summa precis innan auktionen är över. Som vanligt har säkerhetsfunktioner bieffekter, hur länge är det tillåtet att förlänga budgivningen? En viss tid? Ett visst antal bud? Hur skyddar du mot att någon snipear den sista förlängningen? För dyrare objekt är det möjligt att avskräcka genom att sätta en lagom hög minsta-höjning men generellt är det ett svårt problem.

Annars kan man ju alltid DoS:a sajten efter att man har lagt sitt bud så att det blir svårt för övriga att buda över. Det känns dock lite fantasilöst. Vad sägs om att sätta sitt användarnamn till

<script>window.location.href="http://www.aftonbladet.se/";</script>

och sen lägga ett bud så att användarnamnet visas på budsidan.

…vi får se om det blir ett vrakpris. Trevlig helg!

BYOD-säkerhet är en svår gränsdragning

På Skydd 2012 i förra veckan var jag med på en paneldebatt om bring your own device, BYOD. Tyvärr var panelen i princip överens om läget, vilket alltid är tråkigt vid debatter. Jag tänkte oavsett ge min bild av detta hype-omgärdade fenomen som till och med är viktigare än molnet. Vem kunde ha anat?

Det man läser i tidningar om BYOD tenderar vara ganska onyanserat. Ofta låter det som att alla är rörande överens om vad exakt BYOD är för något, frågan är om du har skrivit en säkerhetspolicy eller inte. Så är det inte, BYOD kan betyda vad som helst.

Låt oss börja med att konstatera att BYOD, oavsett vad man rimligen kan mena med det, kommer att sänka säkerhetsnivån. Men, det kanske är värt det.

Med det ur världen… Vad innebär BYOD? Som fan av akademiska, abstrakta definitioner skulle jag säga:

BYOD innebär att organisationen minskar sin kontroll över sina data och ökar användarens kontroll med förhoppningen att det är värt risken.

Minskad kontroll över data, sänkt säkerhetsnivå. Det viktiga är att inse att kontrollen och därmed säkerhetsnivån går att variera. Frågan är hur mycket du är beredd att sänka nivån och hur du avgör om du har sänkt den tillräckligt.

Det här är ju förstås frågor som är omöjliga att besvara entydigt, däremot kan det vara värt att fundera kring olika metoder att sänka sin säkerhetsnivå. (Ja, lite cyniskt uttryckt.) Låt till exempel personal…

  • skicka och ta emot mail på sin privata telefon,
  • koppla upp sig med vpn hemifrån med privat hemdator,
  • dela filer med Dropbox i projektgrupper,
  • använda usb-minnen för att överföra filer fritt eller varför inte
  • ta anteckningar på möten med EverNote på en privat iPad.

Du kanske tycker att den om Dropbox är att tänja på begreppet, jag tycker nog inte det, BYOD handlar inte så mycket om prylarna i sig, snarare om mjukvaran på dem. Jag skulle till exempel inte tycka att det ”räknades” om jag fick ha min egen device men var tvungen att flasha om den enligt arbetsgivarens direktiv. Jag vill ratta arbetsgivarens data med mina egna verktyg, om de sedan kommer på någon särskild hårdvara eller inte spelar ingen roll.

Bring your own tools eller BYOT, vore ett bättre begrepp.

Angående exemplen ovan: är det en stor risk att ha filer på Dropbox? Är det ett problem att hantera mail på privata telefoner? Egna datorer då? I stort rör det sig om två risker man utsätter sig för: (1) risken för dataläckor och (2) risken att de egna verktygen utgör en svaghet i organisationens försvar (läs: någon hackar den anställdes hemdator som har tillgång till företagsnätverket).

Det finns inget recept på hur man ska hantera BYODT, var man ska dra gränsen för säkerhetsnivån. Däremot finns bokstavligt talat hundratals artiklar som tar upp en massa punkter som är nyttiga att tänka på. Exempelvis de sju tips som CIO nämner.

Allt det här förutsätter naturligtvis att dina data är värda att skyddas. Om din verksamhet inte är känslig för dataläckor eller intrång i övrigt och det finns tydliga fördelar med att låta anställda använda sina egna verktyg har du förstås inget att oroa dig över, det är bara att åka.

Däremot, om dina data är skyddsvärda lutar jag dock åt att det är ett för stort risktagande just för att det är svårt att sätta en lagom nivå och avgöra om den är lagom. En okänd risknivå måste anses vara lika med en hög risknivå.

Förutom det som står i alla andra artiklar skulle jag:

  1. göra mig beredd på konsekvenserna av intrång till följd av BYOD-tavlor och
  2. ta tillvara på möjligheten att understryka den anställdes ansvar för de data de hanterar.

Den sistnämnda punkten blir förstås svår som Tomas Djurling påpekade under debatten. Man kan inte göra så mycket mer än att avskeda en person, möjligen i kombination med en rejäl avhyvling om man är lagd åt det hållet, om den har uppvisat grov oaktsamhet. Samtidigt handlar det ju faktiskt om ett givande och ett tagande, som Marcus Ehrstrand från McAfee så elegant uttryckte det under samma debatt.

Under ett sådant här inlägg kan man inte undvika att påpeka att många förmodligen kör med BYOD redan, utan att veta om det. Undersök saken. Om läget är så kan man antingen satsa på att stävja beteendet eller få upp det på bordet, lite som att legalisera spel (eller motsvarande).

Även om en okänd risknivå är att jämföra med en hög risknivå så måste det vara ännu värre att inte veta om att man har en okänd risknivå.

Presenterar på Skydd 2012

Ser man på, jag tillhör eliten. Jag antar att det är vad som händer när säljare säger:

—Förresten, jag skickade in en bio på dig till konferensen.

Anywho… Jag ska alltså presentera på konferensen Skydd 2012 den 19 september klockan 14:30 i Stockholmsmässans sal F1, rubriken är Fastighetsteknik och IT-säkerhet i praktiken. Kolla in programmet (pdf).

Presentationen kommer att handla om hur fastighetsteknik skiljer sig från it, vilka problem fastighetstekniken lider av och, förstås, vad jag tycker att man ska göra åt det. Det är egentligen inga konstigheter, mina åsikter om sånt här skiljer sig inte bara för att det handlar om små, inbyggda datorer i ett litet rum bredvid en hiss i en fastighet jämfört med vanliga datorer med Windows, Linux eller vad det nu kan vara i en serverhall.

Jag kommer att lägga upp presentationen online också. For what it’s worth, jag är en sträng motståndare till Death by Powerpoint™ så mina presentationer brukar vara ganska tråkiga utan tillhörande tal.

Om inget oväntat händer kommer jag också att delta i en paneldebatt om BYOD, något jag faktiskt aldrig har skrivit om på bloggen. Jag tänker mig att jag kör ett blogginlägg i ämnet innan panelen.

Det är förmodligen fredag när du läser det här, så trevlig helg!