IT-säkerhet enligt HPS

Läkare är (fortfarande) ett relativt ansett yrke. Något man inte i lika hög grad kan säga om oss som jobbar med IT. Trots detta har läkare det så enkelt; människokroppen förändras alldeles för långsamt för att man ska behöva ta hänsyn till det. När man har lärt sig hur en fot fungerar, hur matspjälkningen går till och hur man gipsar ett ben, så kan man det. Möjligen behöver man ta till sig nya rön om hur hårt en fot ska lindas, när man ska ge penicillin o s v men huvudsakligen handlar det om att lära sig mer, inte att lära om sig. Inom IT finns det jättemånga varianter av varje kroppsdel, de ändras hela tiden och de kombineras fritt.

Käre läkare, välkommen till vår värld.

Patientjournal
Patienten har vid besöket en ny fot, tyvärr en beta-version som lider av en del barnsjukdomar fortfarande. Leverantören publicerade en uppgradering förra veckan men patienten lät bli att först köra den i testsystemet utan installerade den omedelbart i produktion. Nu kan han inte gå några längre sträckor utan att behöva sätta sig en stund emellanåt. Eftersom promenader inte tillhör patientens kärnverksamhet funderar denne nu på att outsourca detta till Indien. Vidare har patienten problem med att alla strumpor och majoriteten av dennes skor numer inte är kompatibla med foten.

Patientens nuvarande leverantör av knän blev nyligen uppköpt av ett lårföretag som ville ta del av deras senaste teknologi och leverera helhetslösningar. Från sex månader efter uppköpet kommer alla lår och vader att behöva bytas ut eftersom det nya avtalet inte garanterar knäns kompabilitet med andra leverantörers delar. Vad som gäller för gränssnittet mellan vad och fot är fortfarande oklart, förmodligen kommer det att vara möjligt att lösa med specialutvecklad middleware. En workaround bestående av rullstol är en möjlighet.

Patienten bytte för ett år sedan till öppna höfter. Hittills har patienten kunnat använda höfterna någorlunda väl med hjälp av information från diverse Internetforum men eftersom uppdateringar till dem inte har släppts på några år kommer dessa förmodligen att behöva bytas ut. Ett alternativ, för att hålla nere kostnader, är att dela på en jättestor höft ute i molnet.

Patienten har under hösten haft problem med att inköpet av nya händer brast i kravställningen av antal fingrar varför greppförmågan blivit lidande. Upphandling av ytterligare fingrar är pågående men man utreder möjligheten att utveckla egna.

Hoppas att ni hade en lika trevlig midsommar!

--
Stefan Pettersson

Vi hade en diskussion häromdagen där vi gick igenom sårbarheterna (eller är det attackerna?) i OWASP Top Ten. Jag har ju vissa tvivel till den nya utgåvans inriktning men idag gäller det en nytt irritationsmoment. Vän av ordning som man är (skriver ilskna insändare o s v) så trivs jag när saker är distinkta och inte överlappar. OWASP Top Ten lider av vissa problem kring i detta avseende. OWASP Top Ten borde kanske egentligen vara OWASP Top Eight.

1. Injection
2. Cross-Site Scripting (XSS)
3. Broken Authentication and Session Management
4. Insecure Direct Object References
5. Cross-Site Request Forgery (CSRF)
6. Security Misconfiguration
7. Insecure Cryptographic Storage
8. Failure to Restrict URL Access
9. Insufficient Transport Layer Protection
10. Unvalidated Redirects and Forwards

Den första strykningen är enkel att förklara. Cross-site scripting (XSS) är egentligen en form av injection precis som LDAP injection, SQL injection, command injection eller Xpath injection. Vi skulle med gott samvete kunna prata om XSS som HTML injection med browsern som interpreter. Att Javascript tolkas av (förenklat sett) samma tolk förändrar ingenting. Se följande två beskrivningar från OWASP Top Ten 2010:

A1 Injection flaws
Attacker sends simple text-based attacks that exploit the syntax of the targeted interpreter. Almost any source of data can be an injection vector, including internal sources.

A2 Cross-site scripting
Attacker sends text-based attack scripts that exploit the interpreter in the browser. Almost any source of data can be an attack vector, including internal sources such as data from the database.

Den andra strykningen är lite mer subtil. Failure to restrict URL access och insecure direct object reference är båda problem med brister i authorization (vem har tillgång till vad) vilket är en del av paraplyet access control.  I första fallet (A4) avses tillgång till "objekt" och i andra fallet (A8) till "sidor". Förutsatt att sidor visar objekt, hur drar vi den gränsen? Behöver vi dra en gräns? Dessutom, är en sida ett "systemobjekt"? Är en fil ett systemobjekt? Beskrivningarna från 2010-versionen:

A4 Insecure direct object reference
Attacker, who is an authorized system user, simply changes a parameter value that directly refers to a system object to another object the user isn’t authorized for. Is access granted?

A8 Failure to restrict URL access
Attacker, who is an authorized system user, simply changes the URL to a privileged page. Is access granted? Anonymous users could access private pages that aren’t protected.

Hur en applikation gör för att visa sidor, om de lagras som objekt eller inte o s v, är till stor del upp till utvecklaren och ramverket. Oavsett om syntaxen i en sidas URL:er är

http://www.example.com/apage?object=myobject
http://www.example.com/apage?object=notmyobject

eller

http://www.example.com/mypage
http://www.example.com/notmypage

eller

http://www.example.com/show?page=mypage
http://www.example.com/show?page=notmypage

handlar det om samma problem. Vem har tillgång till vad.

Den bästa anledningen till att separera "vanlig" injection och HTML injection (XSS) i vanliga diskussioner är att den förra är en attack mot applikationen medan den senare i regel är en attack mot andra användare. Även detta resonemang haltar dock lite; att sno administratörens cookie via XSS och använda den för att autentisera sig mot applikationen, är det verkligen en attack mot administratören?

Hårklyverier kanske.

--
Stefan Pettersson

Disciplin (från latinets disciplina - uppfostran, handledning, som i sin tur kommer från discipulus - lärjunge, elev). Uppfattas som synonymt med upprätthållande av ordning och regelföljande. [...] En disciplinerad person uppfyller sina åtaganden och handlar i enlighet med sin föreställning om vad som är bäst att göra, även då ett sådant handlande medför ett obehag på kort sikt.

Ovanstående är kopierat från Wikipedia och fångar väl vad disciplin innebär för mig. Vi börjar med lite deduktion (med reservation för osanna premisser):

1. En disciplinerad person uppfyller sina åtaganden.
2. En person som uppfyller sina åtaganden kan man lita på.
3. Man kan lita på en disciplinerad person.

Många associerar disciplin med officerare, gärna i ridstövlar, som skriker åt soldater att fickorna ska vara knäppta. Det är ju förstås inte fel, fickorna ska vara stängda av en anledning. Även om det är jobbigt att behöva öppna och stänga dem varje gång man ska plocka upp eller ner något så måste det göras, annars riskerar man tappa fickans innehåll. Att öppna och stänga fickan är ett "obehag på kort sikt".

Journalisters syn på säkerhet
Ofta när säkerhetsexperter blir intervjuade avslutas intervjun med en fråga i stil med "Kan du nämna ett par enkla steg för ett företag att öka säkerheten?". Sådana frågor är lite förolämpande och ger mig lust att fråga journalisten efter ett par enkla steg för att bygga upp och driva en framgångsrik tidningsredaktion.

De (få) gånger jag ställts inför frågan har jag svarat att ordning och reda är grunden för att kunna öka säkerhetsnivån. Några "enkla steg" som fungerar finns inte. Om du har ordning och reda; vet vilka servrar som finns, vilka tjänster som kör på dessa, vad de används till, vilka som använder dem, när de används, varifrån o s v så har du förutsättningarna för att bestämma vad som får och inte får ske.

Disciplin passar bra in i resonemanget. Det krävs disciplin för att hålla säkerhetsnivån:

• Att byta ut MySQL-root-lösenordet från "demo1234" till något bättre när testsystemet blir produktionssystem.
• Att dokumentera vilken nätverkstrafik som är väntad till och från servern så att brandväggen konfigureras korret.
• Att stänga av och avinstallera den där IMAP-servern som installeras automatiskt med operativsystemet men inte används, trots att den ändå "är bakom en brandvägg".
• Att använda sudo för att genomföra åtgärder som root istället för su så att man får någon form av spårbarhet.
• Att kontrollera den publika nyckeln första gången man loggar in mot en SSH-server.
• Att skriva rutiner i backupscriptet så att den säger till när en backup misslyckas.
• Att inte använda domänadmin-konton för att, slentrianmässigt, logga in på användares datorer.
• Att testa återställningen av backup med jämna mellanrum.
• o s v

Allt det här är exempel på "obehag på kort sikt". Precis som med soldatens ficka så kan man blankt skita i att knäppa den. Det är bekvämt att låta bli. Det är inte säkert att något förloras. På sikt, however, så ökar risken. Med disciplin kan du lita på vilket tillstånd ditt nätverk befinner sig i. Utan disciplin kommer ditt nätverk att bli en knarkarkvart med tiden.

Intressant nog så är det svårt att upptäcka att nätverket är en knarkarkvart. Hade det gällt för kontorslandskapet skulle det ha upptäcks omedelbart så fort besökare kommer. Förhoppningsvis kan vi återkomma till det här.

--
Stefan Pettersson