It-säkerhet enligt HPS

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

Month: oktober, 2012

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!

Annonser

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.