I vår serie om innebygd målbar sikkerhet og BSIMM er vi nå kommet til Security Testing, eller “Sikkerhetstesting”.
Hovedmålet for praksisen Sikkerhetstesting er kvalitetskontroll som gjøres i løpet av utviklingssyklusen. De som utfører sikkerhetstesting må sørge for at sikkerhetsfeil oppdages og korrigeres. Programvaresikkerhetsgruppen (SSG) må sørge for at standarder blir fulgt og at godkjente sikkerhetsmekanismer gjenbrukes.
ST Nivå 1: Forbedre QA utover det funksjonelle perspektivet
QA må omfatte funksjonell kant- og grenseverdi-vilkår-testing i testregimet. Testsamlinger må også omfatte funksjonell sikkerhetstesting.
- ST1.1: Sørg for at QA støtter testing av grenseverdier og tilstander
QA-gruppen går utover ren funksjonell testing til å utføre grunnlegende angrepstester. De undersøker ytterkanter og enkle grensetilfeller. Ingen angrepsferdigheter kreves. Når QA forstår verdien i å komme videre forbi standard funksjonell testing med akseptable innverdier, begynner de langsomt å bevege seg mot “tenke som en angriper”. En diskusjon rundt testing i grenseland fører naturlig til tanken om at en angriper kommer til å føle seg fram i ytterkantene med vilje. Hva skjer når du taster inn feil passord igjen og igjen? - ST1.3: La sikkerhetsmekanismer og sikkerhetskrav drive testene
Testere blinker ut deklarative sikkerhetsmekanismer utledet fra sikkerhetskrav og sikkerhetsegenskaper. En tester kan f.eks. prøve å aksessere administratorfunksjonalitet som en upriviligert bruker, eller verifisere at en brukerkonto låses etter et antall mislykkede innloggingsforsøk. For det meste kan sikkerhetsmekanismer testes på samme måte som andre programvaremekanismer. Sikkerhetsmekanismer basert på krav slik som låsing av brukerkonto, transaksjonsbegrensninger, rettigheter, og så videre testes også. Selvfølgelig er ikke programvaresikkerhet sikkerhetsprogramvare, men det er lett å komme i gang hvis man starter med mekanismer.
ST Nivå 2: Integrér angriperens perspektiv i testplaner
QA må integrere “black-box” sikkerhetstestverktøy i prosessen. QA må bygge testsamlinger for funksjonelle sikkerhetsegenskaper. SSG må dele sin sikkerhetskunnskap og testresultater med QA.
- ST2.1: Integrer “svart-boks” sikkerhetsverktøy i QA-prosessen
Virksomheten bruker et eller flere “svart-boks” (black box) sikkerhetstestverktøy som en del av kvalitetssikringsprosessen. Verktøyene er verdifulle fordi de bygger inn angriperens perspektiv, om enn på en generisk måte. Det finnes forskjellige kommersielle verktøy som er tilgjengelige for web-applikasjoner, og det finnes fuzzing-rammeverk for de fleste nettverksprotokoller. I enkelte situasjoner vil andre grupper samarbeide med SSG for å anvende verktøyene. For eksempel kan et testlag kjøre verktøyet, men gå til SSG for å få hjelp til å tolke resultatene. Uavhengig av hvem som kjører “svart-boks”-verktøyet bør testingen integreres skikkelig i QA-syklusen til SSDL. - ST2.4: Del sikkerhetsresultater med QA
SSG deler rutinemessig resultater fra sikkerhetsgjennomganger med QA-avdelingen. Etter hvert lærer QA-ingeniører seg sikkerhetstankegangen. Bruk av sikkerhetsresultater for å informere og utvikle spesifikke testmønstre kan være en kraftig mekanisme som fører til bedre sikkerhetstesting. Denne aktiviteten tjener på en svært teknisk, ingeniør-fokusert QA-funksjon.
ST Nivå 3: Levér risiko-basert sikkerhetstesting
QA må inkludere sikkerhetstesting i automatiserte regresjonssamlinger. SSG må sørge for denne sikkerhetstestingen, og dybden må veiledes av kunnskap om kodebasen og den assosierte risikoen, i tillegg til aggressiv testing som simulerer angriperens perspektiv.
- ST3.1: Inkludér sikkerhetstester i QA-automatisering
Sikkerhetstester kjører side om side med funksjonelle tester som en del av automatisert regresjonstesting. Det samme automatiserte rammeverket inneholder begge deler. Sikkerhetstesting er en del av rutinene. Sikkerhetstester kan drives med utgangspunkt i abuse cases identifisert tidligere i livssyklusen, eller så kan sikkerhetstester utledes fra kreative tilpasninger av funksjonelle tester. - ST3.2: Utfør fuzzing spesialtilpasset til applikasjonens API
Testingeniører skreddersyr et fuzzing-rammeverk til virksomhetens APIer. De kan begynne fra grunnen av eller bruke en eksisterende fuzzing-verktøykasse, men skreddersømmen går utover å lage tilpassede protokollbeskrivelser eller filformat-maler. Fuzzing-rammeverket har en innebygd forståelse av applikasjonsgrensesnittene det gjør kall mot. Automatiserte test-rammeverk utviklet spesifikt for bestemte applikasjoner kan representere gode steder å integrere fuzzing. - ST3.3: La risikoanalyse-resultater drive testene
Testere bruker resultater fra arkitekturanalyse for å stake ut retningen på arbeidet. For eksempel, hvis arkitekturanalysen konkluderer at “sikkerheten i systemet avhenger av at transaksjonene er atomiske og ikke kan avbrytes/forstyrres halvveis”, så vil avbrutte transaksjoner bli et hovedmål i sikkerhetstestingen. Sikkerhetstester som disse kan utvikles i henhold til risikoprofil – høyrisiko feil først. - ST3.4: Utnytt dekningsanalyse
Testere måler dekningen av deres sikkerhetstester for å identifisere kode som ikke aktiveres. Kode-dekning driver økt sikkerhetstestings-dybde. Standard “svart-boks” sikkerhetstestingsverktøy oppnår svært lav kodedekning, og etterlater hoveddelen av programvaren som skal testes uutforsket. Ikke la dette skje med dine tester. Bruk av standard metrikker for dekning som funksjonsdekning, linjedekning, eller dekning av flere tilstander er i orden. - ST3.5: Begynn å bygge og bruke angrepsorienterte sikkerhetstester (abuse cases)
Testere begynner å inkorporere testtilfeller baser på abuse cases fra SSG. Testere beveger seg forbi å bare verifisere funksjonalitet, og antar angriperens perspektiv. F.eks. kan testere periodisk prøve å gjenskape hendelser hendelser fra virksomhetens historie. Abuse og misuse cases basert på angriperes perspektiv kan også drives fra sikkerhetsinstrukser, angrepsinformasjon og retningslinjer. Dette tar virksomheten opp på neste nivå, fra å teste mekanismer til å prøve å bryte programvaren som testes.