2. Är säkerhet viktigt?

3. Utveckling av “cybercrime”
1986–1995 1995–2003 2004+ 2006+
• LANs • Internet eran • Attacker på OS, DB • Riktade attacker
• Första PC-viruset • “Stora maskar” • Spyware, Spam • “Social engineering”
• Syfte: orsaka skada • Syfte: orsaka skada • Syfte: ekonomiska • Syfte: ekonomi + politik
Marknadspriser 2007
Kreditkortsnummer $0.50 - $20
“Komplett” identitet $1 - $15
Bank-konto $10 - $1000
Source: U.S. Government Accountability Office (GAO), FBI

4. Vart sker attackerna?
20% Sårbarheter i operativsystem
(procent av totalen)
15%
10%
5%
0%
Källa: www.microsoft.com/sir

5. Majoriteten av sårbarheterna hos
ISV’er
3’e parts sårbarheter under 2008
11% 5 största
89% Andra
Sources: IBM X-Force 2008 Security Report

6. Vad gör Microsoft?

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

9. Fungerar det?

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

14. Lite mer detaljer tack!

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

30. Testning ”Release” Sup
Exempel:
X=10 Y=12
4
10/B = 4/12
B = 30 => “fortsätt leta”!

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

34. Ett nyare exempel!

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

36. Agile då?

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

39. www.microsoft.com/sdl
blogs.msdn.com/sdl