7. Tiden som gått…
Idag
• Optimeras
2005-2007 processen genom
analys,
• SDL utökas med automatisering
2004 • “Fuzz” testning
och återkoppling
• Kodanalys • Evangelisera SDL
2002-2003 • Microsoft till “communityn”
• Krav för design
ledningsgrupp av “kryptering” • SDL Process
klubbar att SDL Guidance
• Bill Gates memo: • “Privacy”
ska användas för • SDL Optimization
“Trustworthy alla produkter • “Banned APIs”
Model
Computing” som: • och mer…
• SDL Pro Network
• “Windows • Exponeras för • Windows Vista • SDL Threat
security push” för potentiell risk är det första Modeling Tool
Windows Server och/eller…
OS’et som • SDL Process
2003 • hanterar känslig genomfår hela Templates
information och
• Säkerhets-”push” data SDL cykeln
och FSR förlängs
till andra
produkter
8. Security Development Lifecycle
• Säkra applikationer börjar i säker design
– SDL innehåller både krav och rekommendationer
• Grundprinciper för SDL:
– “Secure by design”
– “Secure by default”
Utbildning Krav Design Kodning Testning ”Release” Support
10. Resultatet...
“..we actually consider
Microsoft to be leading the
software [industry] now in
improvements in their security
development life cycle [SDL]…”
John Pescatore
Vice President and Distinguished Analyst
Gartner, Inc
(From CRN, Feb 13th 2006)
http://tinyurl.com/rezjz
11. SDL fungerar!
• Hur mäter vi framgång?
– Antal säkerhetsrelaterade patchar efter RTM!
12. SDL fungerar!
• Hur mäter vi framgång?
– Antal säkerhetsrelaterade patchar efter RTM!
13. Hur får jag ledningens stöd?
• Hög kvalitet garanterar inte god säkerhet!
• Diskutera inte säkerhet!
– Himlen kanske rasar ned...
• Diskutera integritet och avskildhet (”privacy”)!
– Kunders data och känslig information
– Fakta om uppdateringar och patchar
15. Utbildning Krav Des
• Kontinuerlig process
– Med stöd från ledningen
• Utbilda alla inblandade
– Säker design
– Hotbildsmodellering
– Säker utveckling
– Säkerhetstestning
– Integritet
16. Krav Design Utveckli
• Roller och ansvar
– Ska projektet över huvudtaget använda SDL?
– Vem är totalansvarig för säkerhetsinitiativen?
• Bestäm krav och mål
– Bestäm tidigt ”buggnivån” för tillåten RTM
– Säkerställ verktyg och rapportmöjligheter
• Integritetsmål
17. Design Utveckling T
• Etablera och följ rekommendationer
– Tidigare erfarenheter
• Hotbildsmodellering (”Threat modeling”)
– Alla existerande projekt
– Nya projekt
– Uppdaterade versioner av befintliga projekt
• Dokumentera insamlad information
18. Design Utveckling T
• Hotbildsmodellering
– En process för att förstå hot mot en applikation
• Hot och sårbarheter är inte samma sak:
– Hot: Något som en attackerare kan tänkas
försöka för att “förstöra”
– Sårbarhet: Ett särskilt sätt som ett hot kan
utnyttjas på, exempelvis ett misstag i koden
19. Design Utveckling T
• SDL Threat Modeling Tool
– Vårt egna verktyg för att utvärdera hot mot
produkter och tjänster
– Ladda hem och använd
20. Utveckling Testning ”
• Lita ALDRIG på inmatning!
– Buffer Overruns
– XSS
– SQL Injections
<?php
function filter_sql($input) {
$req = "(delete)|(update)|(union)|(insert)";
return(eregi_replace($reg, "", $input));
}
?>
21. Utveckling Testning ”
• Lita ALDRIG på inmatning!
– Buffer Overruns
– XSS
– SQL Injections
<?php
function filter_sql($input) {
$req = "(delete)|(update)|(union)|(insert)";
return(eregi_replace($reg, "", $input));
}
?>
deldeleteete
22. Utveckling Testning ”
• Lita ALDRIG på inmatning!
– Använd inte bara “black-lists”
• Begränsa
– Tillåt bara det som är korrekt
• Avvisa
– Avvisa det som du vet är dåligt
• Sanera
– Koda om(“encode”), om möjligt
23. Utveckling Testning ”
• Skydda er mot XSS
– Granska alla osäkra punkter för I/O av data
– Använd AntiXss-biblioteket
– Överväg använda HttpOnly-cookies
• Skydda er mot SQL Injection
– Bygg inte upp SQL-uttryck dynamiskt
– Minska “exponeringen” av databasen med
exempelvis vyer och lagrade procedurer
– Använd LINQ
24. Utveckling Testning ”
• Vissa funktioner var OK för 20 år sedan
– Hotbilden ser annorlunda ut
• Vissa är svåra att använda säkert
– Så vi har bannlyst över 120 C funktioner
– Och kommer att fortsätta bannlysa fler
25. Utveckling Testning ”
• Automatisk identifiering och hantering
– Visual Studio 2005 och senare
char buf[32]; char buf[32];
strcpy(buf,src); strcpy_s(buf,src,32);
– SafeCRT eller Strsafe
– #include “banned.h”
• Standard Annotation Language
– Statisk analys
26. Utveckling Testning ”
• Använd senaste krypteringsalgoritmerna
– Använd inte: MD4, MD5, SHA1, DES, RC4
– Använd: SHA2-sviten, AES
• Inga symmetriska nyckar < 128 bitar
• Inga RSA nycklar < 1024 bitar
• Inga svaga slumptalsgeneratorer
• Inga hemligheter i koden
• Var ”crypto-agile”!
27. Utveckling Testning ”
• Kompilator- och länknings-flaggar
– /GS – “Stack Overflow Detection”
– /SAFESEH – “Exception Handler Protection”
– /NXCOMPAT – Använd DEP/NX/XD
– /DYNAMICBASE – Flyttar runt i minnet
• Andra verktyg
– PREfast och FxCop
– AppVerif
– CodeCoverage
28. Testning ”Release” Sup
• “Fuzza” alla filformat som du konsumerar
– Minst 100,000 iterationer per filformat
– Bygg ett “elakt lager”
• ”Security Push”
– Börjar vanligtvis när betan startar
– Dedikerad tid att hitta säkerhetsbuggar
– Inte att laga dem!
29. Testning ”Release” Sup
• ”Jag har biljarder rader kod, så hur prioriterar
jag, och när är jag klar?
X=Buggar som Y=Buggar som
hittats av hittats av
grupp ett N grupp två
Uppskattning om det totala antalet buggar (B) kan fås av:
X/B = N/Y
31. Testning ”Release” Sup
• Granska kod som... • Granska ”mindre” kod som...
– är gammal – är nyare
– alltid är på – är avslagen från början
– körs eleverad – körs med mindre rättigheter
– körs anonymt – körs autentiserat
– lyssnar på nätverket – inte lyssnar på nätverket
– har “Global åtkomst” – är lokal är nyttjar lokala nät
– använder UDP – TCP
– skrivits i C/C++/ASM – är hanterad
– har en historia – har en bra bakgrund
– är komplex – är enkel
– har odokumenterade interface – har dokumenterade gränssnitt
– hanterar känslig information – inte hanterar känslig data
– innehåller stora funktioner – innehåller små funktioner
– är svår att hantera – är enkel att hantera
– har mycket “churn” – är stabil
32. ”Release” Support
• Planera support-processen
– Hur addresseras utmaning av integriteten?
– Hur hanteras ”zero-days exploits”?
– Vem/vilka är ansvariga?
• En sista säkerhetsgranskning (FSR)
– Uppfylls alla krav i SDL?
• Lansering/publicering (RTM/RTW)
33. Support
• Hitta rot-orsaken om/när något uppstår
– Namn och version på fil
– Design eller kodnings-bugg?
– Påverkas andra delar, varför, varför inte?
– Vilka tester kunde ha hittat buggen?
– Vilka verktyg kunde ha hittat buggen?
• Implementera förändringar
– Utbildning, verktyg , processen
35. Silverlight och SDL
• Silverlight har i alla iterationer och
versioner genomgått SDL
– Träning och utbildning
– Analys av konkurrenter och deras utmaningar
– ”Säker” kompilering och användning av SAL
– Kodgranskningar, manuella och automatiska
– Analyser och tester av andra plattformar
• Resultat:
– Inga säkerhetsrelaterade sårbarheter YTD
37. SDL + Agile = Sant!
• Krav kategoriseras annorlunda
• ”Onboarding” - vid uppstart av projektet
• Varje sprint - det absolut viktigaste
• Resten sorteras i tre ”buckets”
– ”Security Verification”
– ”Design Review”
– ”Response Plans”
38. SDL + Agile = Sant!
Varje sprint “Security Verification”
x Hotbilds-modeller x ”Fuzza” inmatning från filer
x Använd ”ValidateRequest” Kör AppVerif
x Andra rekommendationer Andra rekommendationer
“Design Review” “Response Planning”
x Granska ”crypto-design” Krisplan
Granskning av integritet x Uppdatera kontaktpersoner
Andra rekommendationer Andra rekommendationer