Komplexitet och säkerhet: ett exempel

av Stefan Pettersson

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

Annonser