Att skriva säker kod – del 2

1. Att skriva säker kod – del 2 Fredrik Hesse Säkerhetskonsult Nexus Technology AB

2. Agenda • En säker utvecklingsprocess • Hotbildsmodellering • Riskanalys • Rekommendationer och riktlinjer

3. Förbättra utvecklingsprocessen • Tänk på säkerheten… • vid början av processen • genom hela utvecklingscykeln • vid alla milstolpar och “reviews” • vid utrullning och installation • Sluta inte att leta efter säkerhetshål och buggar förrän utvecklingen är helt klar!

4. Säkerhetsramverket SD3 • Säker arkitektur och kod • Hotbildsanalys • Mindre sårbarheter ”Secure bydesign” • Minskad exponering av sårbarheter • Slå av funktioner som inte används • Använd så få rättigheter som möjligt ”Secure bydefault” ”Secure indeployment” • Identifiera, skydda och hantera • Använd riktlinjer, arkitektur • Utbilda personalen

5. Tidslinje Genomför externgranskning Analyserahot Lär av misstagoch applicera Inventerasäkerhetskompetensvid anställning Bestäm kriterierför säkerhet Testa luckoroch sårbarheter Koncept Lansering Efterlansering Design klar Testplanerklara Kodenklar Lös säkerhetsfrågor, verifiera kodmot riktlinjer Utbildadeltagare iprojektet Tester av datapåverkan och minsta rättigheter Genomför granskning avsäkerhetsgrupp =pågående

6. “Secure By Design” • Öka säkerhetskunskapen i designteam • Utbilda kontinuerligt • Utmana attityder – “Det jag inte vet kan inte påverka mig” är fel, fel, fel… • Få säkerheten på plats under designfasen • Definera säkerhetsmål i produkten • Implementera säkerhet som en nyckelfunktion • Använd hotbildsmodellering vid designfasen

7. Agenda • En säker utvecklingsprocess • Hotbildsmodellering • Riskanalys • Rekommendationer och riktlinjer

8. Vad är hotbildsmodellering? • En säkerhetsbaserad analys som: • Hjälper en produktgrupp att förstå var produkten är som mest sårbar • Utvärderar hot och sårbarheter • Har som mål att minska allmäna säkerhetsrisker • Identifierar tillgångar • Exponerar sårbarheter • Identifierar hot • Ska ligga till grund för designspecifikationen om säkerhet

9. Sårbarhet Hot Tillgång Fördelar med hotbildsmodellering • Hjälper dig förstå din applikation bättre • Hjälper dig hitta buggar • Identifierar komplexabuggar i designen • Hjälper till att integreranya medlemmar iutvecklingsteamet • Erbjuder väldesignadeplaner för säkerhetstester

10. Processen Hotbildsmodelleringsprocessen Identifiera tillgångar 1 Skapa en överblick av arkitekturen 2 Dela upp applikationen 3 Identifiera hot 4 Dokumentera hot 5 Rangordna hot 6

11. 1. Identifiera tillgångar • Skapa en lista av tillgångar som kräver skydd, inkludera: • Hemlig data, t.ex. databas över kunder • Webbsidor • Tillgänglighet på systemet • Allt som, om något händer, kommer att påverka tillförlitligheten i din applikation

12. 2. Överblick av arkitekturen • Identifiera vad applikationen gör • Skapa ett diagram över arkitekturen • Identifiera tekniker Filauktorisering URL-auktorisering .NET roller (auktorisering) NTFS rättigheter (auktorisering) Egendefinerade roller (auktorisering) “Trust”-gräns “Trust”-gräns ASPNET (process-identitet) Alice Microsoft SQL Server™ IIS Microsoft ASP.NET Mary Bob IPSec SSL Anonym autentisering “Forms Authentication” Windows autentisering

13. 3. Dela upp applikationen • Bryt ned applikationeni delar • Skapa en säkerhetsprofilbaserat på traditionellasårbarheter • Undersök interaktion medolika system • Använd DFD eller UML Identifiera “Trust”-gränser Identifiera dataflöden Identifiera inmatningstillfällen Identifiera priviligerad kod Dokumentera säkerhetsprofilen

14. 4. Identifiera hot • Sätt samman en grupp • Identifiera hot • Nätverksspecifika hot • Maskinspecifika hot • Applikationsspecifika hot

15. Identifiera hot med STRIDE

16. Använda attackträd 1.0 Se löneinformation (I) 1.1 Traffiken är oskyddad (AND) 1.2 Attackeraren tittar på trafiken 1.2.1 Sniffa traffiken med en ... 1.2.2 Lyssna på trafik på routers 1.2.2.1 Routern är inte uppdaterad (AND) 1.2.2.2 Routern är påverkad 1.2.2.3 Någon gissar routerns lösenord Hot 1 (I) Se löneinformation 1.1 Traffiken äroskyddad 1.2 Attackerarentittar på trafiken 1.2.1 Sniffa trafiken medprotokollövervakare 1.2.2 Lyssna på trafikpå routers 1.2.2.1 Routern är inteuppdaterad 1.2.2.2 Routern ärpåverkad 1.2.2.3 Någon gissarrouterns lösenord

17. 5. Dokumentera hot • Dokumentera hot med hjälp av en mall: • Lämna “Risk” blank (just nu i alla fall)

18. 6. Rangordna hot • Använd formeln: Risk = Chans * Potentiell skada • Använd DREAD att rangordna hot • “Damage potential” • “Reproducibility” • “Exploitability” • “Affected users” • “Discoverability”

19. Exempel: Rangordna hot • “Damage potential” • “Affected Users” eller • “Damage” Hot 1 (I) Se löneinformation 1.1 Traffiken äroskyddad 1.2 Attackerarentittar på trafiken • “Reproducibility” • “Exploitability” • “Discoverability” eller • “Chance” 1.2.1 Sniffa trafiken medprotokollövervakare 1.2.2 Lyssna på trafikpå routers 1.2.2.1 Routern är inteuppdaterad 1.2.2.2 Routern ärpåverkad 1.2.2.3 Någon gissarrouterns lösenord

20. Koda mot en hotbildsmodell • Använd hotbildsmodellering för att hjälpa till med att: • bestämma vilka delar av din applikation som är mest “sårbar” • prioritera säkerhetsfokusering • prioritera pågående kodgranskningar • bestämma vilka lösningstekniker som ska användas • bestämma flödet av data och information

21. Agenda • En säker utvecklingsprocess • Hotbildsmodellering • Riskanalys • Rekommendationer och riktlinjer

22. Riskanalys • Alternativ 1: Gör ingenting! • Alternativ 2: Varna användaren • Alternativ 3: Eliminera problemet • Alternativ 4: Lös problemet

23. NTLM X.509 certifikat PGP nycklar “Basic” “Digest” Kerberos SSL/TLS “Spoofing” Autentisering Processen Hottyp (STRIDE) • Identifiera kategoriExempel: “Spoofing” • Välj teknikerExempel: Autentiseringeller skydda hemligdata Lösningsteknik Lösningsteknik Teknik Teknik Teknik Teknik • Välj teknikExempel: Kerberos

24. Vanliga tekniker STRIDE Konfiguration STRIDE STRIDE • SSL/TLS • IPSec • RPC/DCOM • Stark åtkomstkontroll • Digitala signaturer • Monitorering Osäkertnätverk Autentiserings data • Brandvägg • Minska användningen av resurser för anonyma uppkopplingar Server STRIDE Klient STRIDE Persistent data

25. Agenda • En säker utvecklingsprocess • Hotbildsmodellering • Riskanalys • Rekommendationer och riktlinjer

26. Exekvera med minsta rättigheter • Välkänd säkerhetstes: “Exekvera med tillräckliga rättigheter för att utföra uppgiften, och inte mer!” • Eleverade rättigheter kan få katastrofala konsekvenser • Felaktig och fientlig kod som exekverar i en högt priviligerad process exekverar också med extra rättigheter • Många virus sprids på grund av att mottagaren har administrativa rättigheter

27. Minska exponeringen • Exponera endast begränsade, väldokumenterade gränssnitt i din applikation • Använd bara det som applikationen kräver • Virusen “Slammer” och “CodeRed” skulle inte ha hänt om vissa funktioner varit avslagna som grundinställning • “ILoveYou” (och andra virus) skulle inte ha varit möjliga om exekvering av skript varit avslaget • Slå av allt annat!

28. Lita inte på inmatning • Validera all inmatning • Anta att all inmatning är felaktig • Leta efter korrekt data och neka allt annat • Begränsa, neka och sanera inmatning med • Typkontroller • Längdkontroller • Kontroller på räckvidd • Format Validator.ValidationExpression = "\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*";

29. ISA brandvägg IPSec ISA brandvägg SSL Skydd på djupet (1/3) SQL Server • Använd flera brandväggar IIS

30. Kontrollera säkerhet Kontrollera säkerhet Säkraresursermed ACL:er Kontrollera säkerhet Applikation.dll Applikation.dll Kontrollera säkerhet Skydd på djupet (2/3) • Applicera korrekt nivå av säkerhet i alla nivåer Applikation.exe

31. Skydd på djupet (3/3) • Ta hänsyn till (och använd) ACL:er i applikationen från början • Applicera ACL:er på filer, kataloger, webbsidor, registernycklar, databasfiler, skrivare och objekt i Active Directory • Skapa egna ACL:er vid installation av applikationen • Inkludera DENY ACE:er • Använd inte NULL DACL:er

32. Lita inte bara på “obfuscation” • Dölj inte säkerhetsnycklar i filer • Lita inte på icke dokumenterade registernycklar • Anta alltid att en attackerare kan det du kan och vet det du vet

33. Använda DPAPI • Två funktioner i DPAPI: • CryptProtectData • CryptUnprotectData • Två lagringssätt för data som krypteras: • “User” • “Machine” • Egentligen ett sätt att slippa hantera nycklar!

34. Smart felhantering (1/2) • Se till att hantera eventuella misslyckanden säkert i din kod DWORD dwRet = IsAccessAllowed(...); if (dwRet == ERROR_ACCESS_DENIED) { // Kontrollen misslyckades // Informera användaren om fel } else { // Kontrollen lyckades // Utför uppgift... } Vad händer om IsAccessAllowed() returnerar ERROR_NOT_ENOUGH_MEMORY?

35. Smart felhantering (2/2) • Gör absolut inte detta: • Exponera information i felmeddelanden! • Konsumera resurser under långa perioder efter fel • Men du bör däremot göra detta: • Använd felhantering och skräddarsydda fel för att inte propagera fel tillbaka till användaren • Logga misstänkta fel i händelseloggen <customErrors mode="On"/>

36. Testa säkerheten • Involvera testgrupper från början i projekt • Utveckla en strategi för säkerhetstester • “Think Evil. Be Evil. Test Evil.” • Automatisera attacker med skript och lågnivåspråk • Mata in en mängd felaktig data • Ta bort eller neka åtkomst till filer och registret • Testa med ett konto som inte är en administratör • Lär känna din fiende och lär känna dig själv! • Vilka tekniker kommer hackers använda? • Vilka tekniker ska dina testare använda?

37. Lär av misstag! • Om du hittar ett säkerhetsproblem, lär dig från det! • Hur uppstod felet? • Kan det existera någon annanstans i koden? • Hur kunde det ha förhindrats? • Vad bör göras för att förhindra repetition? • Behövs en uppdatering av utbildningsmaterial eller analysverktyg?

38. Summering • En säker utvecklingsprocess • Hotbildsmodellering • Riskanalys • Rekommendationer och riktlinjer

39. Nästa steg! • Var uppdaterad och informerad! • Svensk sida om säkerhet för utvecklare:www.microsoft.se/msdn/security • Senaste riktlinjerna:www.microsoft.com/security/guidance/ • Mer träning och utbildning: • Workshops och labbar:www.microsoft.se/msdn/security • Kurser hos CTEC:www.microsoft.com/learning/

40. Kontrollskott • Nämn några olika hot! • Svar: • På vilka plattformar finns DPAPI? • Svar: • Vad är STRIDE? • Svar:

41. Nästa presentation • Säkerhet i .NET Framework • Kod och bevisbaserad säkerhet • WSE