It-säkerhet enligt HPS

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

Kategori: Säkerhet

Muntlig övning ger också färdighet

Säkerhet för information kräver, precis som nationell säkerhet (läs: militär), övning.

Tyvärr finns det inte så många bra, vägledande exempel som är allmänt kända. Rick Rescorla som evakuerade Morgan Stanley från WTC är i och för sig ett men det är inte direkt it, övningar som Cyber Europe förekommer ibland men det är samarbete mellan stater,  emellanåt görs mindre övningar i disaster recovery lokalt på företag, det rör dock inte attacker.

Jag tänker mig lokala övningar som är scenariobaserade, oförberedda och som genomförs i verkligheten. Precis i stil med den övning som Facebook genomförde i höstas:

Early on Halloween morning, members of Facebook’s Computer Emergency Response Team received an urgent e-mail from an FBI special agent who regularly briefs them on security matters. The e-mail contained a Facebook link to a PHP script that appeared to give anyone who knew its location unfettered access to the site’s front-end system. […]

The FBI e-mail, zero-day exploit, and backdoor code, it turns out, were part of an elaborate drill Facebook executives devised to test the company’s defenses and incident responders. The goal: to create a realistic security disaster to see how well employees fared at unraveling and repelling it.

Jag ryser när jag läser artikeln. Fan vad bra. Trots detta är det alltså flera som ”absolut inte” vågar skicka privata meddelanden med Facebook.

Säkerhet handlar bara delvis om att förhindra intrång, att kunna upptäcka och agera är viktigare. Det är ett exempel på generella åtgärder mot specifika sårbarheter.

Tyvärr är de oerhört resurskrävande, ett billigare alternativ är det Försvarsmakten kallar muntliga stridsövningar. De kan förstås genomföras med mer eller mindre resurser, men på enklaste sätt:

  1. Samla patrullen,
  2. ge orientering om läget (”tivinote” för de som lärde sig den),
  3. delge patrullens order och
  4. ”prata igenom” hela lösandet av uppgiften från början till slut med hjälp av en karta.

Chefen som leder övningen ska förstås se till att lösandet inte går för smidigt utan regelbundet ta upp omfall: vad gör vi om det eller det händer?

Jag föreslog det här för den ansvarige på en säkerhetsgrupp på ett relativt litet svenskt företag för något år sen. Som alla andra så kämpade de med att de inte hade tillräckliga resurser. Trots detta verkade det som att de nästan alltid hade en timme över på fredagar efter klockan två…

Mitt förslag hette Halvtimmen (mest för att Timmen lät lite avskräckande, det kommer förmodligen att ta en timme), tanken var att man skulle samlas i ett konferensrum varje fredag, presentera ett scenario och sedan diskutera vad man skulle göra om det hände idag.

Det är två outputs som är relevanta här. Dels blir man snabbt varse om hur (dålig) kontroll man har, hur mycket man borde ha gjort tidigare och hur liten chans man har att hantera det (resurserna igen). Men framförallt blir man tvungen att öva, och det kostar inte mer resurser än den där halvtimmen eller timmen.

Om det dessutom kombineras med eftermiddagsfika är det ännu lättare att klämma fram ”gratistid”. Om du har rätt personal i säkerhetsgruppen kommer de gladeligen byta ut en ”vanlig” fika mot Halvtimmen.

Jag kan förstås inte publicera originalförslaget men jag hittade lite av mina anteckningar kring förslag på scenarion. Det går att komma på hur många som helst.

Halvtimmen

För varje scenario ska man fokusera på tre frågor:

  • Vad gör vi för att hantera situationen på en gång?
  • Hur borde vi har förberett oss på situationen?
  • Hur kan vi undvika att situationen uppstår i framtiden?

Den första frågan omfattar den muntliga stridsövningen, de övriga två fångar erfarenheter och det är dessa som kräver resurser utöver halvtimmen. Hör av dig om ni har tillämpat liknande muntliga övningar tidigare, det vore intressant att höra erfarenheter.

Annonser

Det finns inga gratiskrav

Det finns inga gratiskrav.Det här är en post-it som sitter strax till höger om min skärm vid skrivbordet. Den är till för att påminna mig om att påminna personer i min närhet om att ”Det finns inga gratiskrav”.

I mina ögon är säkerhetskravställning lite av en konst. Inte för att det är svårt, på sätt och vis är det ganska enkelt att ställa säkerhetskrav: det finns en hel industri kring it-säkerhet som har tagit fram saker från säkerhetsövervakningsavdelningar till MAC och allt där i mellan.

När du sitter med ett system under utveckling och ska formulera säkerhetskrav har du hur många krav som helst att välja på. Häri ligger konsten, du kan inte ställa hur många som helst för förr eller senare ska kraven uppfyllas; någon ska implementera MAC-kontrollen eller organisera säkerhetsövervakningsavdelningen och det kostar resurser i tid och pengar.

Att välja säkerhetskrav

Varje säkerhetskrav kostar resurser och sådana är alltid begränsade. Konsten är att ställa de säkerhetskrav som ger mest bang for the buck. Säkerhetskrav kostar olika mycket resurser och bidrar med olika mycket säkerhet så i grunden handlar det om en cost/benefit-analys för varje krav.

Är den säkerhet som kravet bidrar med värd besväret?

För att kunna svara på denna fråga måste man har koll på tre saker:

  1. Vad kostar kravet?
  2. Hur mycket säkerhet ger kravet?
  3. Vilket behov av säkerhet finns?

Tyvärr finns inga exakta svar på någon av frågorna, det finns inte ens ganska exakta svar, så vi kan sällan räkna på det med siffror. (Jag refererar till två äldre inlägg: Att mäta säkerhet på Internetdagarna och Att mäta säkerhet igen.)

Jag sprang på ett fantastiskt citat igår kväll på tal om det här, ett av ekonomilegenden Keynes (nu såg jag att det inte alls var han utan tydligen Carveth Read):

It is better to be vaguely right than exactly wrong.

Det kommer att handla om olika bra uppskattningar till svaren. Man ska göra avvägningen i alla fall; men man måste acceptera att det inte är en exakt vetenskap och handla därefter. Det här leder ofta till något som det är modernt att hata inom säkerhet; något som slarvigt kallas magkänsla. Jag gnäller en del över det i Att mäta säkerhet igen-inlägget om du är på humör för sånt, annars lägger vi det åt sidan.

Av de tre frågorna följer att alla säkerhetskrav inte är lika mycket värda. Vissa saker ger mycket säkerhet för lite resurser medan andra ger förhållandevis lite säkerhet i utbyte mot stora resurser. De förstnämnda är no-brainers, de sistnämnda kräver analys; kanske är just den lilla säkerhetsdetalj som erbjuds ett måste som inte går att uppnå på något annat sätt? Kanske kan vi inte avgöra riktigt utan blir tvungna att köra för att vara på säkra sidan?

Rabatt på säkerhetskrav

När vi ändå har börjat tala i ekonomiska termer kan vi lika gärna fortsätta, men det får bli nästa gång. Trevlig tredje advent!

Sekretessbelagt, hemligt, konfidentiellt och känsligt

En av mina pet peeves är slarv med terminologi. Det är en peeve som inte har tjänat mig så väl, ingen gillar någon som tycker att sådana detaljer är viktiga. Så, jag försöker ligga lågt till vardags, med undantag för idag.

Hemligstämpel

Inom säkerhetsområdet är ett vanligt mål att hindra obehöriga från att ta del av vissa data. Varför då? Av någon anledning är obehörig åtkomst oönskat; vissa data är nämligen:

  • sekretessbelagda,
  • hemliga,
  • konfidentiella eller
  • känsliga.

Data kan vara allihop eller bara vissa av dem. Låt oss utgå från lösenorden som finns i databasen till en webbapplikation; är de sekretessbelagda, hemliga, konfidentiella eller känsliga?

Sekretessbelagt är sådana uppgifter (läs: data) som omfattas av offentlighets- och sekretesslagen (2009:400) eller, populärt, OSL.

…förresten, som vanligt när jag citerar lagar så bör du beakta att IANAL.

Det här gör det väldigt enkelt; inget annat (IANAL-varning utfärdas) än det som är upptaget i OSL är sekretessbelagt. Sverige har nämligen en blacklist-modell för sina lagar: det som inte är otillåtet är tillåtet. Det är bara en av de saker som är så fina med fria samhällen, det kanske till och med är definitionen på dem.

Det är inte strikt fel att säga att lösenorden till användare i en webbapplikation är sekretessbelagda eftersom 18 kap. 8 § säger följande:

Sekretess gäller för uppgift som lämnar eller kan bidra till upplysning om säkerhets- eller bevakningsåtgärd, om det kan antas att syftet med åtgärden motverkas om uppgiften röjs och åtgärden avser […] 4. behörighet att få tillgång till upptagning för automatiserad behandling eller annan handling

…men om du inte arbetar på sektionen för ärendehantering på en myndighet och precis sitter och handlägger en ansökan om att få ta del av den allmänna handlingen ”listan över riksdagsföreträdares lösenord” så är det nog inte vad du menar.

Intressant i sammanhanget OSL är att Sverige har klampat med smutsiga skor över Kerckhoffs princip i nästa paragraf:

9 § Sekretess gäller för uppgift som lämnar eller kan bidra till upplysning om chiffer, kod eller liknande metod, om det kan antas att syftet med metoden motverkas om uppgiften röjs […]

Jag knyter näven i byxfickan. En annan intressant men irrelevant paragraf är:

14 § Sekretess gäller för uppgift i kopior som i säkerhetssyfte har genererats i Regeringskansliets datasystem och som har bevarats med anledning av naturkatastrofen i Asien år 2004, om det inte står klart att uppgiften kan röjas utan fara för att Regeringskansliets verksamhet skadas.

Tala om specifikt; konspirationsteoretiker förenen eder. Vi går vidare.

Hemliga uppgifter är en delmängd av de sekretessbelagda, d v s allt som är hemligt är också sekretessbelagt men inte nödvändigtvis tvärtom. Vad som är hemligt definieras av säkerhetsskyddsförordningen (1996:63) i fjärde paragrafen (min fetstil):

I denna förordning avses med […] 1. hemlig uppgift: uppgift som omfattas av sekretess enligt offentlighets- och sekretesslagen (2009:400) och som rör rikets säkerhet […]

Nu börjar det ta sig. Nästa fråga är vad som gör att något ”rör” rikets säkerhet och då blir det genast svårt eftersom ”rikets säkerhet” inte är definierat i lag. Säkerhetspolisen har en kanonbra text som heter Säkerhetsskydd – en vägledning (pdf) som säger följande:

Någon legaldefinition av begreppet rikets säkerhet finns inte. Rikets säkerhet kan dock sägas avse såväl den yttre säkerheten för det nationella oberoendet som den inre säkerheten för det demokratiska statsskicket. Begreppet rikets säkerhet vållar ibland svårigheter och bekymmer i säkerhetsskyddsarbetet. Något exakt svar på vad som är rikets säkerhet finns inte, utan det är upp till varje myndighet att själva undersöka vilka uppgifter som ska hållas hemliga i förhållande till rikets säkerhet.

Där har ni det. Om vår webbapplikation är ett gränssnitt för att reglera temperaturen för Ringhals 2 kan man nog framgångsrikt argumentera för att lösenorden är hemliga. Samma kan man nog göra om det är ett dokumenthanteringssystem som används vid ett utvecklingsprojekt av nya pansarvärnsrobotar till Försvarsmakten. De omfattas av 18 kap. 8 § OSL samt rör rikets säkerhet. I praktiken så betraktas dock allt som omfattas av försvarssekretess som hemligt.

Kvalificerat hemlig

Det finns ytterligare en benämning, kvalificerat hemlig, jag är osäker på var det definieras dock så om någon vet är ni välkomna att kommentera. Det används emellertid då röjande skulle innebära synnerligen stor skada för rikets säkerhet. De kännetecknas ofta av att det är två ramar runt stämpeln (eller att det står kvalificerat hemlig, förstås).

Nu är det tyvärr slut med lagreferenser.

Kvar finns konfidentiell och känslig, de betyder inget särskilt utan kan användas fritt utan att behöva oroa sig för missförstånd. I och för sig kan det väl ske vissa missförstånd vid användning av det senare begreppet eftersom det kan gälla både lösenord och kroppsdelar men det är nog inget att oroa sig över.

(Uppdatering: missa inte Kim Hakkarainens kommentar nedan för ytterligare nomenklatur-pekpinnar.)

Fuskbyggen revisited: två skillnader

Title: Samsung Printer Backdoor Account

Description: Network-aware printers manufactured by Samsung before October 31, 2012 (including some Dell printers actually built by Samsung) have a hard-coded SNMP read-write community string, which enables full administrative access to the device – even when SNMP has been disabled by the user. A patch is currently being developed by Samsung; in the interim, users should consider blocking all SNMP traffic to impacted printers, which likely contain sensitive information that could be used by an attacker or industrial spy.

Reference:
http://www.kb.cert.org/vuls/id/281284
http://l8security.com/post/36715280176/vu-281284-samsung-printer-snmp-backdoor

Det här möts man av i veckans @RISK-nyhetsbrev från SANS (min fetstil). Jag skrev om fuskbyggen tidigare, alla fuskbyggen är dock inte jämlika, det finns skillander.

Skillnad #1: det finns buggar och det finns buggar

Buggar och säkerhetsbuggar har alltid funnits och kommer alltid att finnas. I samma nyhetsbrev som ovan rapporteras också CVE-2012-5533, en DoS-bugg i lighthttpd: genom att skicka ett request med en header där en token är tom hamnar servern i en oändlig loop och slutar svara. Det är ett misstag som är lätt att göra och förvisso går det att upptäcka sånt genom testning, problemet med kombinatorisk explosion gör dock att det är omöjligt att täcka alla testfall. Med andra ord, sådana här buggar kommer att dyka upp emellanåt. Deal with it.

En hårdkodad community string på en skrivares SNMP-server är en helt annan bugg. Det är förresten ingen bugg, det är slarv. Att strängen dessutom verkar har funnits sedan 2004(!) gör det bara mer besvärande. Det är helt enkelt inte okej.

Skillnad #2: det finns mjukvaror och det finns mjukvaror

Det är en sak om ett företag utvecklar mjukvara som de ska använda själva, och slarvar. De flesta har inget problem med någon som binder ris för egen rygg. Däremot, om företaget utvecklar mjukvara med avsikt att sälja den – kräva pengar i utbyte för att någon ska få använda den – och slarvar. Det är helt enkelt inte okej.

Eller finns det förmildrande omständigheter?

Varför är Bildts Gmail ett säkerhetsproblem?

I lördags gick Aftonbladet ut med nyheten att utrikesminister Carl Bildt använder en privat Gmail-adress för officiell kommunikation:

Enligt uppgift till Aftonbladet har Bildt uppmanat höga tjänstemän inom utrikesförvaltningen att kontakta honom på Gmail-adressen i stället för hans officiella via Utrikesdepartementet. Kommunikationssättet ska vara utbrett bland svenska ambassa­dörer trots att systemet är ifrågasatt.

– Gmail är inte säkert. Informationen ligger lagrad på servrar i andra länder. Det är ett amerikanskt företag som inte tvekar att lämna ut material till säkerhetstjänster, säger Joakim von Braun, it-säkerhetsexpert.

Flera källor uppger att Bildt föredrar att kommunicera via sin Ipad, men det har inte varit problemfritt.

Fotografi av Aftonbladets framsida

Både molntjänster och BYOD alltså? Hualigen.

Låt oss först och främst konstatera att säkerhetsproblemen med gmail.com i stort också gäller riksdagen.se (eller var hans formella mail nu ligger), den viktiga skillnaden är att man saknar kontroll över Gmail; det är svårt eller omöjligt för Riksdagens säkerhetsfolk att övervaka, kontrollera eller anpassa säkerheten hos Google.

Vilka säkerhetsproblem riskerar Bildt i praktiken?

Först och främst, (1) med tillgång till Bildts Gmail-konto kan man förstås läsa allt som har skickats och tagits emot. Enligt utsago så ska inget omfattas av sekretess och det kanske stämmer. Bildt är ju en rätt van politiker och har säkerligen koll på vad han skickar, frågan är om de som skickar mail till honom har det.

(2) Någon som får åtkomst till Bildts Gmail-konto kan utge sig för att vara honom, det kan förstås få oanade konsekvenser.

(3) Någon som får åtkomst till Bildts Gmail-konto kan ta bort de mail som har skickats och tagits emot eller varför inte, byta lösenord eller avsluta kontot? Så mycket för allmänna handlingar som kan vara offentliga.

(4) Dessutom, som Jocke nämner i artikeln, servrarna som Bildts mail bor i ägs av ett företag i ett annat land och kan därför bli tvungna att lämna ut åtkomst till myndigheter på ett eller annat sätt. Detta var aktuellt nyligen i samband med Petraeus-affären där en CIA-chef kommunicerade med en älskarinna via Gmail och kraftigt underskattade sina motståndares (FBI) kapacitet.

Faktum är att även om Bildt använder precis samma mailtjänst som ”vanliga” människor så är hans konto utsatt för större risk. Dels för att han är en offentlig person och därför har en större hotbild men också för att han är en offentlig person och därför har avsevärt svårare att lyckas med s k social authentication som är vanlig i sådana sammanhang. För självklart är det lättare att ta reda på svaret till den offentliga Bildts ”hemliga fråga” än hans okände namnes i Häggvik. (Ja, det finns en till Carl Bildt, Henric Robert Carl Bildt närmare bestämt.)

Uppdatering samma dag: Såg nu också att Bildt (på ett härligt bildtskt vis) har kommenterat saken på sin blogg. Tyvärr gör han det något amatörmässiga misstaget att likställa säkerhet med skydd mot att information läcker. Det är ju, enligt ovan, bara ett av problemen.

Förberedelser i bild

Det här fotot har cirkulerat i mer än en vecka nu men det förtjänar det. Fotot är taget av en fotograf på Reuters medan stormen Sandy låg över New York och New Jersey. Lägre Manhattan i mörker med hotfulla moln över, en fastighet lyser som om inget har hänt. 200 West St, Goldman Sachs huvudkontor.

Det här handlar förstås uteslutande om att Goldman Sachs var mer förberedda än sina grannar, vilket de var medvetna om:

We wanted to take this opportunity to let you know that we have strong business continuity plans in place at Goldman Sachs Asset Management and are open for business. Most NY-based employees are working from home or are partnering with their global and US counterparts to cover important items.  Our portfolio management teams are actively engaged and are closely monitoring our client portfolios.

Anledningen är att de har räknat på hur mycket pengar de förlorar (läs: inte tjänar) om de måste avbryta handeln. (Enligt en bekant med god insyn i detta så handlade Goldman ”som fan” under hela Sandy.)

Jag återberättade för några år sen historien om Morgan Stanleys säkerhetschef Rick Rescorla och den 11 september. En fantastisk historia som förmodligen inte är helt sann men ändå är bra och framförallt illustrativ.

Trevlig helg!

Fuskbyggen

Hem- och inredningsprogram på tv har ju varit populära ett bra tag nu. En speciell variant som jag gillar är de som handlar om fuskbyggen. Det finns flera exempel, jag gillar kanadensiska Holmes on Homes men i Sverige har vi förstås Martin Timell och Lennart Ekdal i serien Fuskbyggarna.

Varje program har egentligen samma upplägg: en familj bor i ett hus där hela eller delar av huset är dåligt byggt. Först går programledarna runt i huset och ojjar sig över hur byggarna har slarvat. Det har använts spik när det egentligen borde ha varit skruv, man har hällt ner spackel i avlopp, struntat i dränering och fuktspärrar, nöjt sig med vanligt gips i våtutrymmen, snålat med material, gjort livsfarliga kabeldragningar, etc, etc.

Resten av programmet ägnas åt att göra om allt på rätt sätt. Ordentligt. Från början. Holmes är särskilt anal och tvekar inte en sekund på att riva upp golvet på hela undervåningen bara för att det är golvknarr vid en tröskel någonstans. Man skulle kunna säga att det är p-rr för oss som lider av viss perfektionism. Som en bonus söker sedan Ekdal upp byggaren och hänger ut vederbörande.

Jag funderar på att höra av mig till Strix eller Jarowskij med en ny programidé: Fuskutvecklarna. Jag skulle dock ersätta Timell och Ekdal med Paulie Gualtieri och Kjell Bergqvist.

I kvällens program av Fuskutvecklarna: Alexander och Linneas leverantör av middleware för realtidsmeddelandehantering mellan deras webbfront och affärssystem sade att systemet var säkert. Alexander och Linnea var nöjda i början men efter några månader visade det sig att stora delar av systemet var utvecklat i en blandning av Java, PHP och Lua-script ovanpå Mandrake  med en sju år gammal Linuxkärna. Den inbyggda databasen visade sig ha hårdkodade lösenord och var åtkomlig via fem olika portar som inte gick att stänga. Den, enligt utsago, ”härdade” plattformen körde strax över 300 processer efter en fräsch omstart, bland annat Apples Bonjour, Samba och en OSPF-router.

När Linnea hörde av sig med klagomål hävdade leverantören att allt var implementerat i hårdvara och därför inte behövde säkerhetspatchar samt att den oavsett uppfyllde FBI:s säkerhetskrav.

Se när Paulie och Kjell hjälper Alexander och Linnea att styra upp sin meddelandehantering och sedan konfronterar leverantören.

Now that’s television.

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.