Yrityksessäni työskentelemme ottamalla käyttöön Microsoftin suojatun kehityksen elinkaaren, ja osa MSDL-prosessia sisältää tietoturva- ja tietoturvavirheiden perustamisen alussa Olen kuullut virhepalkin käsitteen ennen MSDL: ää ja ymmärrän, että se on olennaisesti määritelmä siitä, minkä tason / määrän vikoja olet valmis hyväksymään lopputuotteessa, mutta olen en ole koskaan ymmärtänyt kuinka virhepalkki luodaan projektille. Onko virhepalkkien luomiseen olemassa hyvin dokumentoituja prosesseja, joista voin oppia?
Olen yrittänyt tehdä Googlella esimerkkejä tai tosielämän skenaarioita projekteista. virhepalkkien määritteleminen projektin alkaessa, mutta en näytä saavan hyviä tuloksia tai vinkkejä virhepalkin luomisesta. MSDL-esimerkkejä näyttää olevan valmiita virhepalkkeja, mutta olen kiinnostunut oppimaan jotain tämän kaltaisen määrittelyprosessista. Esimerkiksi niille, jotka ovat tehneet jotain tällaista aiemmin, oletko määrittänyt vikapalkit hyvin erityisellä tavalla (esim. Sanomalla " Luvatonta tiedostojärjestelmän käyttöä ei saa olla: lukeminen tiedostojärjestelmä "), vai oletko käyttänyt lykättyä lähestymistapaa sanoessasi, kun löydämme vikoja, luokittelemme ne asteikolla 1–5 (5 on vakavin), määritä nyt Että mitään vikoja yli 3 ei lähetetä, ja jätä vikaluettelosi, kunnes ne löydetään? Minusta tuntuu, että yrittää tehdä ensimmäinen on typerää ja mahdotonta toimintaa, mutta myöhemmällä on taipumus olla puolueellinen kohti lempeyttä, kun projekti on tulossa langalle.
Jälleen, käärimällä kaikki tämä yhteen ytimekkääseen kysymykseen, voiko kukaan tarjota minulle hyvin dokumentoidun lähestymistavan virhepalkkien määrittelemiseen / luomiseen?
Vastaus
Let ” Aloitetaan virhepalkin perusmäärittelystä:
Laatuportteja ja virhepalkkeja käytetään määrittämään turvallisuuden ja yksityisyyden laadun hyväksyttävä vähimmäistaso. on neuvoteltava laatuportit (esimerkiksi kaikki kääntäjän varoitukset on luokiteltava ja korjattava ennen koodin sisäänkirjautumista) jokaiselle kehitysvaiheelle. Virhepalkki on laatuportti, jota käytetään määrittämään tietoturva-aukkojen vakavuusrajat – esimerkiksi sovelluksessa ei ole tunnettuja haavoittuvuuksia, joiden luokitus on ”kriittinen” tai ”tärkeä” julkaisuhetkellä. Kun virhepalkki on asetettu, sitä ei pitäisi koskaan rentouttaa.
Kun ohjelmiston käyttäjä arkistoi virheraportin, hänen on määritettävä virheelle STRIDE-luokka riippumatta siitä onko kyseessä asiakas- tai palvelinvirhe ja mihin vikaan vaikuttaa. Käyttäjät voivat olla ohjelmistokehittäjiä ja laadunvalvonnan henkilöstöä. STRIDE tarkoittaa:
- huijaus
- peukalointi
- hylkääminen
- tietojen paljastaminen
- palvelunestäminen (DoS)
- Käyttöoikeuksien korotus (EoP)
Asiaankuuluvat ”laajuus” -arvot ovat
- Asiakas – väärennetty luotettu käyttöliittymä yleinen / oletusskenaario
- Asiakas – väärennetty luotettu käyttöliittymä tietyssä muussa skenaariossa
- asiakas – väärennetty käyttöliittymä osana suurempaa hyökkäystilannetta
- palvelin – väärennetty käyttäjä tai tietokone suojatun protokollan kautta
- Palvelin – väärennetty satunnainen käyttäjä tai tietokone suojatun protokollan kautta
- Asiakas – Luotetut luotettavat tiedot, jotka jatkuvat uudelleenkäynnistyksen jälkeen
- Asiakas – Väärennetyt tiedot, jotka ei jatku uudelleenkäynnistyksen jälkeen
Sieltä luodaan matriisi, joka antaa jokaiselle yhdistelmälle vakavuustason. Vakavuusasteen mahdolliset arvot ovat:
- Kriittinen
- Tärkeä
- Kohtalainen
- Matala
- Ei mitään
Esimerkki syötteestä matriisiin (tällaisia merkintöjä voi olla useita):
STRIDE Luokka: Huijaus
Laajuus: Client – väärennetty luotettu käyttöliittymä tavallisessa / oletustilanteessaKuvaus: Hyökkääjän kyky esittää käyttöliittymä, joka eroaa käyttöliittymästä, mutta on visuaalisesti identtinen käyttöliittymän kanssa, johon käyttäjien on luotettava tehdessään kelvollisia luottamuspäätöksiä oletus / yleinen skenaario. Luottamuspäätös määritellään milloin tahansa, kun käyttäjä ryhtyy toimintaan uskoen, että tietty entiteetti – joko järjestelmä tai jokin tietty paikallinen tai etälähde – esittää tietoja.
Vakavuustaso: Tärkeää
Microsoft väittää korjaavansa kaikki virheet, jotka ovat tärkeämpiä kuin ”matala”, ennen käyttöönottoa.
Lisätietoja
Suojausvirhepalkin lisääminen Microsoft Team Foundation Server 2010: een
Uusi SDLC: tietoturvakehityksen elinkaari