It-säkerhet enligt HPS

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

Tagg: saltzer-schroeder

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

Ye Olde Security: Saltzer-Schroeder

För länge, länge sedan, på 1970-talet, inte långt efter vi tågade över Bält och skrämde slag på danskarna, levde två lärda män som hette Jerome H. Saltzer och Michael D. Schroeder. Saltzer och Schroeder var forskare och hade stora anslag för att undersöka hur information kunde skyddas i system för ADB. 1973 skrev de sitt magnum opus: The Protection of Information in Computer Systems.

 Saltzer-Schroeder-uppsatsen är ett fantastiskt exempel på att vi stöter på samma problem om och om igen. I texten hittar vi nuggets som de åtta designprinciperna (mer om dessa nedan):

  1. Economy of mechanism
  2. Fail-safe defaults
  3. Complete mediation
  4. Open design
  5. Separation of privilege
  6. Least privilege
  7. Least common mechanism
  8. Psychological acceptability

Med kommentaren: ”As is apparent, these principles do not represent absolute rules—they serve best as warnings. If some part of a design violates a principle, the violation is a symptom of potential trouble, and the design should be carefully reviewed to be sure that the trouble has been accounted for or is unimportant.”

Eller varför inte: ”In particular, the user himself and the communication system connecting his terminal to the computer are components to be viewed with suspicion. Conversely, the user needs to verify that he is in communication with the expected computer system and the intended virtual machine.”

Eller vad sägs om: ”An easy way for an intruder to penetrate a password system, for example, is to intercept all communcations to and from the terminal and direct them to another computer—one that is under the interceptor’s control. This computer can be programmed to ‘masquerade,’ that is, to act just like the system the caller intended to use, up to the point of requesting him to type his password. […]”

Economy of mechanism: Designa små, enkla system. Ju enklare desto mindre risk att sårbarheter införs, desto enklare är det att upptäcka dem och desto lättare är det att laga dem.

Fail-safe defaults: Själv brukar jag göra skillnad på fail-safe och fail-secure (egentligen är det väl Schneier som har inspirerat distinktionen i Beyond Fear) eftersom de ofta står mot varandra; nödutgångar är skolexemplet. Här avses oavsett att normalläget är ingen åtkomst och att systemet istället ska definiera under vilka förutsättningar åtkomst ges. Whitelisting kontra blacklisting.

Complete mediation: Varje anrop eller åtgärd ska omfattas av säkerhetsbeslut viz. det ska inte finnas ”bakdörrar” som går förbi det som konceptuellt kallas en reference monitor. Faktum är att detta var ett av de tre kraven på en reference monitor som James P. Anderson lade fram i Computer Security Technology Planning Study från 1972. (Den rapporten är också gammal men avsevärt mer svårsmält.)

Open design: Kerckhoffs princip.

Separation of privilege: Här avses snarare det vi idag oftast kallar defense in depth, att säkerheten inte ska bero på bara en försvarslinje. Man ger exemplet där en dörr har två oberoende lås vars nycklar kan förvaras av olika personer på olika platser. Dels handlar det om att göra det svårt för en tredje person att få tag i båda nycklar, dels för att skydda sig mot insiders. Det är inte uttalat i uppsatsen men man kan argumentera för att låsen kan vara av olika modell för att för att skydda sig mot sårbarheter i ett lås. Eller använda helt olika tekniker för att skydda sig mot class breaks.

Least privilege: Det här kan vara den mest kända principen och är precis vad den låter som. Militärens need-to-know används som exempel. Den är givetvis nära besläktad med fail-safe defaults ovan.

Least common mechanism: Detta tangerar segmentering, att minimera gemesamma kontaktytor mellan användare (processer). Eftersom multi-level security-system (Bell-LaPadula o s v) var på tapeten vid den här tiden så var informationsläckage och covert channels ett stort bekymmer. Samtidigt rörs det vi idag kallar process isolation där en modern, närliggande teknologi är t ex Windows Integrity Mechanism som kom med Vista.

Psychological acceptability: Gör det lätt för användaren att fatta rätt säkerhetsbeslut. Nuförtiden skulle jag dock lägga till ”men undvik helst att blanda in användaren överhuvudtaget”. Problemet med principen är att ”användare” i början av 70-talet inte, som idag, betydde Joppe och Göran, utan diverse forskare och programmerare. Att inte blanda in användaren i säkerhetsbeslut är tyvärr fortfarande en utopi, principen borde dock användas för att mildra problemet med dancing pigs.

Så, trots 40 år på nacken är principerna precis lika aktuella idag.

Såg just att kollega Christoffer också har skrivit om gammal hederlig säkerhet och enkelhet, ta en titt.

Trevlig påsk!