It-säkerhet enligt HPS

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

Tagg: enkelhet

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å!

Politik, ekonomi, juridik, byråkrati och säkerhet

I juli 2010 införde amerikanarna en ny lag: Dodd-Frank Wall Street Reform and Consumer Protection Act. Dodd-Frank ska reglera finansmarknaden, tydliggöra ansvar, öka transparens och skydda medborgare från att i framtiden behöva rädda banker som hamnat i ekonomiskt obestånd p g a orimlig riskexponering.

Med subprime-idiotin i bakvattnet är Dodd-Frank förståelig. Men även om avsikten är god så kan genomförandet halta. I förra veckans the Economist (bl a Over-regulated America och Too big not to fail) beskrivs Dodd-Frank och omdömet är sådär. Huvudsakligen kretsar kritiken kring att lagen är (1) för omfattande, (2) för komplicerad och (3) kräver mycket energi för att följa. Min fetstil:

But Dodd-Frank is far too complex, and becoming more so. At 848 pages, it is 23 times longer than Glass-Steagall, the reform that followed the Wall Street crash of 1929. Worse, every other page demands that regulators fill in further detail. Some of these clarifications are hundreds of pages long. Just one bit, the ”Volcker rule”, which aims to curb risky proprietary trading by banks, includes 383 questions that break down into 1,420 subquestions. […] Hardly anyone has actually read Dodd-Frank, […]

Som vanligt är jag ju ute på djupt vatten här när jag kommenterar amerikansk finanslagstiftning men Dodd-Frank är ett perfekt exempel på något som gör mig trött: onödig komplexitet.

Komplicerade system — oaktat om det är lagar, mailservrar, flygplatser eller scriptfiler…

  • har effekter som är svåra att förutse,
  • har förmodligen oväntade bieffekter,
  • tar lång tid att förstå sig på,
  • är svåra att göra kontrollerade ändringar i,
  • är jobbiga att granska,
  • är krångliga att optimera,
  • är problematiska att avveckla,
  • är hemska att felsöka och
  • saknar elegans (hemska tanke).

N.B. Allt är dock inte negativt; det är fullt möjligt att komplicerade system går snabbare att designa än enklare system med motsvarande funktionalitet. Enkla lösningar är i regel svårare att tänka sig än de som är onödigt sammansatta. I övrigt är de dock bättre på alla sätt man kan tänka sig.

Beroende på vem du är kan i o fonödig komplexitet vara en fördel; amerikanska jurister gnuggar sannerligen händerna över Dodd-Frank…

Komplexa system riskerar alltid s k emergent properties (ungefär framväxande egenskaper) vilket är samma sak som överraskande bieffekter men avser just interaktion mellan olika delar av komplexa system. Definitivt inte önskvärt i säkerhetssammanhang. Schneier återkommer till det här många gånger i sin bok Beyond Fear; en av mina biblar. Jag är multireligiös.

Det mest bedrövande med just Dodd-Frank är att det är en lag. Lagar skyddar mot oönskade handlingar. Lagar är säkerhetssystem. Allt som kan angripas är säkerhetssystem. De kan således ha sårbarheter eller säkerhetshål; även om de i lagsammanhang oftast kallas kryphål (oklart varför).

Det ironiska är att den onödiga komplexiteten förmodligen har ökat med försöken att eliminera just kryphålen. Samtidigt säger den fundamentala lagen om säkerhet och enkelhet att antalet sårbarheter/kryphål måste öka med komplexiteten.

Kanske var det bättre förr, som en juristkollega sade, när en bra domare ansågs stå över en dålig lag.

Hälsa och säkerhet

Bloggrannen Cornucopia? skrev i veckan om AstraZenecas förargliga varsel i Södertälje och fick en kommentar från en läsare (Cornus fetstil):

Precis min spaning; och jag råkar vara utbildad läkare. Att KI eller AZ skulle syssla med att främja människors ”hälsa” är naturligtvis skrattretande absurt. Deras levebröd är just att människar har ohälsa, och där finns alltså inget som helst incitament att främja någon ”hälsa”. Hälsa främjas, precis som du skriver, av motion, tallriksmodellen, solsken, meningsfullt socialt liv, närhet, och i bästa fall kärlek. Lejonparten av dagens läkemedel har i princip syftet att minska biverkningarna från felaktig kost, stillasittende, och ensamhet. Att främja hälsa är extremt enkelt och billigt – mycket svårt att tjäna pengar på dvs. Att producera molekyler kallade läkemedel har däremot stora profitmarginaler.

Det kan vara det nyktraste jag läst på länge och jag kan inte låta bli att dra paralleller till säkerhetsbranschen. Det är svårt att tjäna pengar på säkerhetsarbete genom att:

  1. Förorda ordning, reda och disciplin.
  2. Hävda att man inte ska lägga all kraft på att förebygga problem.
  3. Säga att säkerhet är enkelt, det handlar bara om att göra det.
  4. Förespråka öppenhet gällande säkerhetsproblem.
  5. Tjata om att övning är viktigt.

Vad sysslar jättarna i branschen med? De stora är de som utvecklar och säljer produkter. Jag undrar om det verkligen är att gå för långt att använda den andra meningen i citatet ovan för att beskriva de flesta.

Analogin haltar lite. Vi har nämligen en extraordinär omständighet i vår bransch, något vi i princip bara delar med Polisen och Försvarsmakten; vi har intelligenta, antagonistiska motståndare. Motståndare gör säkerhet svårt. Inom ”hälsovården” har man inga intelligenta motståndare.

Det är fortfarande en mycket tänkvärd liknelse.