Säker utveckling med SDL

1,127 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,127
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Säker utveckling med SDL

  1. 1. Är säkerhet viktigt?
  2. 2. 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
  3. 3. Vart sker attackerna? 20% Sårbarheter i operativsystem (procent av totalen) 15% 10% 5% 0% Källa: www.microsoft.com/sir
  4. 4. 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
  5. 5. Vad gör Microsoft?
  6. 6. 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
  7. 7. 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
  8. 8. Fungerar det?
  9. 9. 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
  10. 10. SDL fungerar! • Hur mäter vi framgång? – Antal säkerhetsrelaterade patchar efter RTM!
  11. 11. SDL fungerar! • Hur mäter vi framgång? – Antal säkerhetsrelaterade patchar efter RTM!
  12. 12. 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
  13. 13. Lite mer detaljer tack!
  14. 14. Utbildning Krav Des • Kontinuerlig process – Med stöd från ledningen • Utbilda alla inblandade – Säker design – Hotbildsmodellering – Säker utveckling – Säkerhetstestning – Integritet
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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)); } ?>
  20. 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)); } ?> deldeleteete
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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”!
  26. 26. 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
  27. 27. 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!
  28. 28. 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
  29. 29. Testning ”Release” Sup Exempel: X=10 Y=12 4 10/B = 4/12 B = 30 => “fortsätt leta”!
  30. 30. 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
  31. 31. ”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)
  32. 32. 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
  33. 33. Ett nyare exempel!
  34. 34. 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
  35. 35. Agile då?
  36. 36. 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”
  37. 37. 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
  38. 38. www.microsoft.com/sdl blogs.msdn.com/sdl

×