Säker utveckling med SDL

Är säkerhet viktigt?

Utveckling av “cybercrime”

• LANs

• Första PC-viruset

• Syfte: orsaka skada

1986–1995

• Internet eran

• “Stora maskar”

• Syfte: orsaka skada

1995–2003

• Attacker på OS, DB

• Spyware, Spam

• Syfte: ekonomiska

2004+

• Riktade attacker

• “Social engineering”

• Syfte: ekonomi + politik

2006+

Marknadspriser 2007

Kreditkortsnummer $0.50 - $20

“Komplett” identitet $1 - $15

Bank-konto $10 - $1000

Source: U.S. Government Accountability Office (GAO), FBI

Vart sker attackerna?

Källa: www.microsoft.com/sir

0%

5%

10%

15%

20% Sårbarheter i operativsystem (procent av totalen)

Majoriteten av sårbarheterna hos ISV’er

11%

89%

3’e parts sårbarheter under 2008

5 största

Andra

Sources: IBM X-Force 2008 Security Report

Vad gör Microsoft?

Tiden som gått…

2002-2003

2004

2005-2007

Idag

• Bill Gates memo: “Trustworthy Computing”

• “Windows security push” för Windows Server 2003

• Säkerhets-”push” och FSR förlängs till andra produkter

• Microsoft ledningsgrupp klubbar att SDL ska användas för alla produkter som:

• Exponeras för potentiell risk och/eller…

• hanterar känslig information och data

• SDL utökas med

• “Fuzz” testning

• Kodanalys

• Krav för design av “kryptering”

• “Privacy”

• “Banned APIs”

• och mer…

• Windows Vista är det första OS’et som genomfår hela SDL cykeln

• Optimeras processen genom analys, automatisering och återkoppling

• Evangelisera SDL till “communityn”

• SDL Process Guidance

• SDL Optimization Model

• SDL Pro Network

• SDL Threat Modeling Tool

• SDL Process Templates

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

Fungerar det?

“..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

Resultatet...

SDL fungerar!

• Hur mäter vi framgång?

– Antal säkerhetsrelaterade patchar efter RTM!

SDL fungerar!

• Hur mäter vi framgång?

– Antal säkerhetsrelaterade patchar efter RTM!

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

Lite mer detaljer tack!

• Kontinuerlig process

– Med stöd från ledningen

• Utbilda alla inblandade

– Säker design

– Hotbildsmodellering

– Säker utveckling

– Säkerhetstestning

– Integritet

Utbildning Krav Design Utveckling Testning ”Release” Support

• 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



• Etablera och följ rekommendationer

– Tidigare erfarenheter

• Hotbildsmodellering (”Threat modeling”)

– Alla existerande projekt

– Nya projekt

– Uppdaterade versioner av befintliga projekt

• Dokumentera insamlad information


• 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


• SDL Threat Modeling Tool

– Vårt egna verktyg för att utvärdera hot mot produkter och tjänster

– Ladda hem och använd


• Lita ALDRIG på inmatning!

– Buffer Overruns

– XSS

– SQL Injections

<?php function filter_sql($input) { $req = "(delete)|(update)|(union)|(insert)"; return(eregi_replace($reg, "", $input)); } ?>



– Buffer Overruns

– XSS

– SQL Injections

deldeleteete

<?php function filter_sql($input) { $req = "(delete)|(update)|(union)|(insert)"; return(eregi_replace($reg, "", $input)); } ?>



– 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


• 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


• 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


• Automatisk identifiering och hantering

– Visual Studio 2005 och senare

– SafeCRT eller Strsafe

– #include “banned.h”

• Standard Annotation Language

– Statisk analys

char buf[32];

strcpy(buf,src);

char buf[32];

strcpy_s(buf,src,32);


• 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”!


• 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


• “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!


• ”Jag har biljarder rader kod, så hur prioriterar jag, och när är jag klar?

Uppskattning om det totala antalet buggar (B) kan fås av:

X=Buggar som hittats av grupp ett

Y=Buggar som hittats av grupp två N

X/B = N/Y


Exempel:

X=10 Y=12 4

10/B = 4/12 B = 30 => “fortsätt leta”!


• Granska kod som... – är gammal – alltid är på – körs eleverad – körs anonymt – lyssnar på nätverket – har “Global åtkomst” – använder UDP – skrivits i C/C++/ASM – har en historia – är komplex – har odokumenterade interface – hanterar känslig information – innehåller stora funktioner – är svår att hantera – har mycket “churn”

• Granska ”mindre” kod som... – är nyare – är avslagen från början – körs med mindre rättigheter – körs autentiserat – inte lyssnar på nätverket – är lokal är nyttjar lokala nät – TCP – är hanterad – har en bra bakgrund – är enkel – har dokumenterade gränssnitt – inte hanterar känslig data – innehåller små funktioner – är enkel att hantera – är stabil


• 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)


• 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

Ett nyare exempel!

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

Agile då?

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”

SDL + Agile = Sant!

Hotbilds-modeller

Använd ”ValidateRequest”

Andra rekommendationer

Granska ”crypto-design”

Granskning av integritet


”Fuzza” inmatning från filer

Kör AppVerif


Krisplan

Uppdatera kontaktpersoner


Varje sprint

“Design Review”

“Security Verification”

“Response Planning”

x

x

x

x

x

x

www.microsoft.com/sdl

blogs.msdn.com/sdl

Säker utveckling med SDL

Technology