Presentation laddar. Vänta.

Presentation laddar. Vänta.

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

Liknande presentationer


En presentation över ämnet: "Fredrik Hesse Säkerhetskonsult Nexus Technology AB Att skriva säker kod – del 2."— Presentationens avskrift:

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

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 SD 3 ”Secure in deployment” ”Secure by design” ”Secure by default”  Säker arkitektur och kod  Hotbildsanalys  Mindre sårbarheter  Minskad exponering av sårbarheter  Slå av funktioner som inte används  Använd så få rättigheter som möjligt  Identifiera, skydda och hantera  Använd riktlinjer, arkitektur  Utbilda personalen

5 Testplaner klara Designklar Koncept Koden klar Lansering Efter lansering Testa luckor och sårbarheter Inventera säkerhetskompetens vid anställning Bestäm kriterier för säkerhet Genomför extern granskning Analysera hot Lär av misstag och applicera Genomför granskning av säkerhetsgrupp Utbilda deltagare i projektet Tester av datapåverkan och minsta rättigheter Lös säkerhetsfrågor, verifiera kod mot riktlinjer =pågående Tidslinje

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  Hjälper dig förstå din applikation bättre  Hjälper dig hitta buggar  Identifierar komplexa buggar i designen  Hjälper till att integrera nya medlemmar i utvecklingsteamet  Erbjuder väldesignade planer för säkerhetstester Fördelar med hotbildsmodellering Hot Sårbarhet Tillgång

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

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 NTFS rättigheter (auktorisering) Filauktorisering URL-auktorisering.NET roller (auktorisering) Egendefinerade roller (auktorisering) SSL “Trust”- gräns Alice Mary Bob IIS Anonym autentisering “Forms Authentication” IPSec “Trust”-gräns ASPNET (process-identitet) Microsoft ASP.NET Microsoft ASP.NET Windows autentisering Microsoft SQL Server™

13 Identifiera “Trust”-gränser Identifiera dataflöden Identifiera inmatningstillfällen Identifiera priviligerad kod Dokumentera säkerhetsprofilen 3. Dela upp applikationen  Bryt ned applikationen i delar  Skapa en säkerhetsprofil baserat på traditionella sårbarheter  Undersök interaktion med olika system  Använd DFD eller UML

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

15 Identifiera hot med STRIDE HottypExempel S poofing  Förfalska epostmeddelanden  Repetera autentiseringspaket T ampering  Ändra data vid transport  Förändra data i filer R epudiation  Ta bort en fil och neka  Köpa en produkt och neka I nformation disclosure  Exponera information i felmeddelanden  Exponera kod på webbsidor D enial of service  Överrösa ett nätverk med SYN-paket  Överrösa ett nätverk med förfalskade ICMP-paket E levation of privilege  Utnyttja buffertöverskrivningar  Olovligen få administrativa rättigheter

16 Hot 1 (I) Se löneinformation 1.1 Traffiken är oskyddad 1.2 Attackeraren tittar på trafiken Sniffa trafiken med protokollövervakare Lyssna på trafik på routers Routern är inte uppdaterad Routern är påverkad Någon gissar routerns lösenord 1.0 Se löneinformation (I) 1.1 Traffiken är oskyddad (AND) 1.2 Attackeraren tittar på trafiken Sniffa traffiken med en Lyssna på trafik på routers Routern är inte uppdaterad (AND) Routern är påverkad Någon gissar routerns lösenord Använda attackträd

17  Dokumentera hot med hjälp av en mall:  Lämna “Risk” blank (just nu i alla fall) HotbeskrivningSQL Injection Mål för hot Komponenter för dataåtkomst Risk Attacktekniker Attackerare lägger in SQL-kommandon i användarnamn, som används för att skapa ett SQL-program Motstånd Använda reguljära uttryck för att validera användarnamnet, och en lagrad procedur med parametrar för att få åtkomst till databasen, få rättigheter behövs 5. Dokumentera hot

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  “Damage potential”  “Affected Users” eller  “Damage”  “Reproducibility”  “Exploitability”  “Discoverability” eller  “Chance” Exempel: Rangordna hot Hot 1 (I) Se löneinformation 1.1 Traffiken är oskyddad 1.2 Attackeraren tittar på trafiken Sniffa trafiken med protokollövervakare Lyssna på trafik på routers Routern är inte uppdaterad Routern är påverkad Någon gissar routerns 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 Hottyp (STRIDE) Lösningsteknik Teknik “Spoofing”Autentisering NTLM X.509 certifikat PGP nycklar “Basic” “Digest” Kerberos SSL/TLS 1.Identifiera kategori Exempel: “Spoofing” 2.Välj tekniker Exempel: Autentisering eller skydda hemlig data 3.Välj teknik Exempel: Kerberos Processen

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

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 Validator.ValidationExpression =  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

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

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

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  Två funktioner i DPAPI: –CryptProtectData –CryptUnprotectData  Två lagringssätt för data som krypteras: –“User” –“Machine”  Egentligen ett sätt att slippa hantera nycklar! Använda DPAPI

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

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

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! 1.Var uppdaterad och informerad! –Svensk sida om säkerhet för utvecklare: –Senaste riktlinjerna: 2.Mer träning och utbildning: –Workshops och labbar: –Kurser hos CTEC:

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

42


Ladda ner ppt "Fredrik Hesse Säkerhetskonsult Nexus Technology AB Att skriva säker kod – del 2."

Liknande presentationer


Google-annonser