First Tuesday Bergen 7 juni 2011

1. Smidig sikkerhet
Sikkerhet som en naturlig del av utviklingsprosessen
den agile
First Tuesday Bergen
7. juni 2011

2. Lars Hopland Nestås
• MSc fra UiB, Institutt for informatikk:
«Building Trust in Remote Internet Voting»
• Konsulent i Bouvet ASA siden august 2010
• Risiko- og sårbarhetsanalyser
• Sikkerhetstesting av webapplikasjoner
• Kildekodegjennomgang
• Utvikler (Java og PHP)
• Sikkerhetskurs i regi av Bouvet
2

3. Oversikt
• Forvaltningsteam i Bouvet
– Fordeler
– Utfordringer
• Sikkerhet som en naturlig del av
utviklingsprosessen
– Microsoft SDL
– Hva og hvordan gjør vi det i forvaltningsteamet?
3

4. Mediabildet
4

5. Forvaltningsteamet i Bouvet
• 6 konsulenter +/-
• Java, PHP, iPhone og Android
• Benytter Scrum som prosjektmetodikk
• Utvikling av nye løsninger
• Forvaltning av eksisterende løsninger
Noen
kunder
siste
6
mnd.
5

6. Fordeler
• Godt miljø for deling av kompetanse
• Flere konsulenter har kompetanse og kunnskap til
å utføre arbeid på alle prosjektene (god overlapp)
• Kunden betaler kun for utført arbeid
Utfordringer
• Ofte bytte av uviklingsmiljø
• Sikkerhet som en naturlig del av
utviklingsprosessen
– Mange små uviklingsoppgaver
• En «typisk» oppgave er estimert til 4-8 timer
6

7. Sikkerhet som en naturlig del av
utviklingsprosessen
7

8. MS Security Development Lifecycle
«So now, when we face a choice between adding features
and resolving security issues, we need to choose security.»
8 http://www.microsoft.com/security/sdl/

9. Aktiviteter i SDL*
Manuell og
automatisert testing
Analysere angrepsflate Verifisering av Sikker
Sikkerhetstrening
og utarbeide trusselmodell og forvaltning
trusselmodell angrepsflate
Opplæring Design Verifikasjon Oppfølging
Kravspek. Implementasjon Produksjon
Etablere målbilde
for sikkerhetsnivå Spesifisere verktøy Utarbeide
beredskapsplan
Analysere Håndheve
implementasjons- Sikkerhetsgjennomgang
sikkerhets- og
personvernsrisiko regler
Arkivering av
Statisk
sikkerhetsrelatert
kodeanalyse
prossessdokumentasjon
9 *Fritt etter MS Security Development Lifecycle

10. Sikker programutvikling*
Opplæring
Kravspek.
Design
Implementasjon
Verifikasjon
Produksjon
Oppfølging
10 *Etter mal fra MS Security Development Lifecycle

11. Agile Security Development Lifecycle
Manuell og
automatisert testing Håndheve
implementasjons-
Verifisering av regler
Sikkerhetstrening trusselmodell og
angrepsflate
Spesifisere verktøy
Arkivering av Sikkerhetsgjennomgang
sikkerhetsrelatert
prossessdokumentasjon Analysere Analysere
angrepsflate og sikkerhets- og
utarbeide personvernsrisiko
Etablere målbilde trusslemodell
Statisk
for sikkerhetsnivå
Utarbeide kodeanalyse
beredskapsplan
Ak:viteter
i
hver
sprint Engangsak:viteter Regelmessige
ak:viteter

12. Agile Security Development Lifecycle
Analysere angrepsflate og
utarbeide trusselmodell
Analysere sikkerhets- og
personvernsrisiko
Verifisering av
Håndheve trusselmodell og
implementasjonsregler angrepsflate
Arkivering av Spesifisere verktøy Manuell og
sikkerhetsrelatert Etablere målbilde automatisert testing
prossessdokumentasjon for sikkerhetsnivå Sikkerhetsgjennomgang
Statisk
kodeanalyse Utarbeide
Sikkerhetstrening
beredskapsplan
Ak:viteter
i
hver
sprint Engangsak:viteter Regelmessige
ak:viteter

13. «SDL» i forvaltningsteamet
13

14. Opplæring
• Kurs i applikasjonssikkerhet
– Kjennskap til mest vanlige angrepsteknikkene
– Lære å beskytte seg mot de vanligste angrepene
– Lære å identifisere sårbarheter/typiske problemområder i
applikasjoner og kildekode
– Kjennskap til noen verktøy for testing
– Strategi for sikker programutvikling
14

15. Opplæring
Oppgave
8
-­‐
Lagret
XSS
• Legge inn ondsinnet kode i kommentarfelter i forumet
• Hint 1: Utvikleren prøver å vaske inndata ved å fjerne
<script>-tagger for å hindre at brukere kan legge inn
javascript
Oppgave
12b
-­‐
SQL
injec:on
• Hent filen etc/passwd ved hjelp av SQL-injection
15

16. Kravspesifikasjon og design
• Utføres som workshop sammen Analysere
angrepsflate
med kunden for å kartlegge:
– Informasjonsverdier
Design
– Angrepsflate
Kravspek.
– Aktører
• Angrepsscenario (Misuse cases)
Etablere målbilde
– Alle deltakerene rangerer for sikkerhetsnivå
scenarioene etter kritikalitet (lav til
Analysere
kritisk) hver for seg sikkerhets- og
personvernsrisiko
• Inngår som en viktig del av
trusselmodellen
16

17. Eksempel på angrepsscenario for aktøren «elev»
1 Ta over andre brukersesjoner
2 Endre passord på andre brukeres konto
3 Oppgradere egen konto til admin
Kri:sk
4 Levere oppgave for annen elev
5 Lesetilgang til andre elevers innleveringer
6 Gi andre elever utvidede rettigheter
7 Endre åpne- og lukketid for innleveringsmapper
8 Gi andre eller seg selv ekstratid på oppgaveinnleveringer
9 Lese kommentarer på andre elevers oppgaver
Stor
10 Legge til kommentarer på egne og andre elevers oppgaver
11 Opprette nye kontoer
12 Endre oppgavesammendrag på andre elevers innleveringer
13 Lese oppgavesammendrag på andre elevers innleveringer
Middels
14 Hindre at andre elever får levert oppgave (DoS-angrep)
15 Motta e-postvarsel når andre elever leverer oppgaver
16 Slette egne innleveringer
Lav
17 Se hvem som ikke har levert oppgave
17

18. Angrepsscenario
• Inngår som grunnlag i:
– Utarbeidelse av kravspesifikasjon
– Implementasjonsfasen for å identifisere typiske
«problemområder»
– Verifikasjonsfasen
– Utarbeidelse av beredskapsplan og i
sikkerhetsgjennomgang før produksjon
– Forvaltningsfasen ved utvikling av ny funksjonalitet
18

19. Implementasjon og verifikasjon
• For hver ny utviklingsoppgave utarbeider
utvikleren en testplan før implementeringen
begynner
• Testplanen inneholder:
– Kort beskrivelse av ny funksjonalitet
– Kort beskrivelse av hvordan dette implementeres/løses
– Krav til kodekvalitet
– Krav til sikkerhet
• En annen konsulent gjennomfører testplanen
innenfor estimatet for oppgaven
19

20. Eksempel på testplan:
• Som administrator vil jeg kunne slå av og på
logging for de ulike web servicene
Testkriterier
Funksjonalitet/Løsningsbeskrivelse:
Administrator for XXX skal ha mulighet til å aktivere og deaktivere logging av feil for de ulike WS (xxx.php og
zzz.php). Administrering av dette skjer i http://localhost:8888/xxx/yyy/zzz/index.php.
Når logging aktiveres/deaktiveres via admin-grensesnittet lagres i filen debug_config.php som ligger i mappen X.
Skriving til debug_config.php skjer via zzz/debug_admin.php som kalles via admin-grensesnittet
Kodekvalitet:
• Skal være formattert iht. etablert standard
• Koden skal være enkel å lese og ha gode kommentarer
Sikkerhet:
• Skriving til filer som skal inkluderes i applikasjonen kan være skummelt. Alle verdier som lagres i filen skal
være hardkodet (dvs. ingen inndata fra brukeren skal skrives til fil).
20

21. Oppsummering
• Opplæring
• Workshop for å utarbeide angrepsscenario
• Testplaner for alle utviklingsoppgaver
– Manuell testing av applikasjonen med fokus på sikkerhet
– Koderevisjon
– Kompetanseheving
• Automatiserte tester ved hjelp av verktøy
• Statisk kildekodeanalyse (i nær fremtid)
21

22. Spørsmål?
22

23. Takk!
Lars
Hopland
Nestås
lars.nestas@bouvet.no
23