Mäluturvalisuse teekaart on plaan, kus on määratud vastutajad ja tähtajad, ning selle saate koostada sel kvartalil, puudutamata enamikku oma C ja C++ koodist. Ümberkirjutamine tuleb hiljem ja hõlmab ainult need osad, mis seda õigustavad. Praegu on vaja selget ülevaadet sellest, kus ebaturvaline kood asub, viisi selle ohjeldamiseks ning kirjalikku jälge otsustest, mille te tegite.
CISA dokument The Case for Memory Safe Roadmaps kirjeldab, kuidas tarkvaratootjad saavad mäluturvalisuse haavatavuste kõrvaldamiseks liikuda mäluturvalistele keeltele (MSL). Dokument palub tootjatel teekaardid avaldada, et kliendid näeksid, kuidas tootjad turvatulemuste eest vastutavad, rakendaksid radikaalset läbipaistvust ja järgiksid ülalt-alla lähenemist. Need on Secure by Design põhimõtted ning dokument on suunatud nii juhtidele kui ka inseneridele. See teine sihtrühm on oluline: teekaart ilma toetaja ja sponsorita jääb wikisse seisma.
Mida allikad katavad ja mida mitte
CISA kokkuvõtlik leht mainib ainult üleminekut MSL-idele ning teekaardi koostamist ja avaldamist. Dokumendi täielikku sisu see ei näita, mistõttu me ei väida midagi selle kohta, mida dokument ütleb fuzzingu või protsesside isolatsiooni kohta. Need kaks allpool toodud sammu on meie enda praktika aastateks, mis jäävad hetke "meil on täna C++" ja hetke "olulistes osades on meil turvalisem keel" vahele. Käsitlege neid ajutiste kontrollimeetmetena, mitte teekaardi asendajana.
Allikad ei anna ka arve selle kohta, kui palju riski üks või teine samm kaotab. Me ei hakka neid välja mõtlema. Mõõtke seda ise, tuginedes oma krahhide ja haavatavuste ajaloole.
1. samm: inventeerige ebaturvaline kood
Seda, mida te pole loetellu kandnud, ei saa prioriseerida. Koostage tabel komponendi, mitte repositooriumi kohta, sest üks repositoorium segab sageli kokku rahulikult rahule jäetava utiliidi ja võrguparseri.
| Väli | Miks see on oluline |
|---|---|
| Keel ja standard | Näitab, mida saab migreerida ja mida mitte |
| Kättesaadav väljastpoolt? | Võrk, fail, USB, jadaliides, uuenduskanal |
| Parsib ebausaldusväärset sisendit? | Määrab fuzzingu ja ümberkirjutamise prioriteedi |
| Millise õigusega töötab? | Määrab, kui palju isolatsioon aitab |
| Kolmanda osapoole või meie oma? | Määrab, kes saab vea parandada |
| Vastutaja ja viimane sisuline muudatus | Surnud koodi saab sageli eemaldada |
Lisage vendored teegid ja püsivara (firmware) komponendid. Eriti riistvarameeskondadel on bootloaderites, draiverites ja uuenduskäsitlejates sageli vana C-koodi, mida pole aastaid keegi avanud. Needki komponendid väärivad oma rida.
2. samm: isoleerige see, mida te veel asendada ei saa
Küsige iga komponendi kohta, mis on märgitud kättesaadavaks ja ebausaldusväärset sisendit parsivaks: mis juhtub, kui see on täielikult kompromiteeritud? Kui vastus on "kõik", on see teie esimene disainimuudatus. Viige parser eraldi protsessi, võtke selle õigused ära ning eemaldage selle juurdepääs failidele, soketitele ja võtmetele, mida see ei vaja.
See ei paranda viga. See piirab, kui palju viga ründajale väärt on. See sobib kokku eesmärgiga, mille NIST sõnastab dokumendis Secure Software Development Framework (SP 800-218): leevendada selliste haavatavuste ärakasutamise võimalikku mõju, mida te pole veel leidnud.
3. samm: fuzzige sisenemispunktid
Võtke oma inventuurist komponendid, mis parsivad ebausaldusväärset sisendit, ja kirjutage igaühele fuzz harness. Käivitage harnessid CI-s ajalimiidiga ning hoidke krahhide korpust alles. Valige esmalt failivormingud, protokollisõnumid ja uuenduspaketid, sest need on teed, mille kaudu väline osapool pääseb ligi.
Ehitage fuzzingu binaarid sisselülitatud kompilaatori mäluvigade tuvastusega, et vaikne üle lugemine muutuks nähtavaks veaks. Iga läbivaadatud krahh annab teile midagi, mida teekaart vajab: tõendi selle kohta, millised komponendid väärivad ümberkirjutamist. Kui harness ei leia pikemate käivituste järel midagi, on ka see kasulik ning lubab selle komponendi madalamale reastada.
4. samm: valige lühike ümberkirjutamise nimekiri
Kasutage kolme esimest sammu kandidaatide valimiseks. Hea esimene ümberkirjutus vastab järgmistele tingimustele:
- See parsib ebausaldusväärset sisendit.
- Sel on kitsas liides, nii et seda saab sama API taga asendada.
- See on fuzzingul krahhe tekitanud või sel on vigade ajalugu.
- See on piisavalt väike, et üks meeskond saaks selle valmis ühe-kahe väljalaskeperioodiga.
Jätke stabiilne, sisemine ja väljapoole mittenähtav kood C või C++ keelde ning öelge seda teekaardis selgelt. Komponendi juurde kirjutatud "ei ole plaanis, isoleeritud, fuzzitud" on aus ja klientidel on sellega võimalik töötada. See on meie tõlgendus radikaalsest läbipaistvusest: te avaldate oma seisukoha ning mitte iga rida ei pea lõppema ümberkirjutamisega. CISA kokkuvõte nimetab põhimõtet, kuid ei ütle, mida see tähendab komponentide jaoks, mis jäävad C või C++ keelde.
Uued komponendid on odavaim koht alustamiseks. Otsustage kohe, millist keelt uus võrku suunatud kood kasutab, ning kirjutage see oma inseneristandarditesse.
5. samm: kirjutage see üles ja siduge oma protsessiga
NIST kirjeldab SSDF-i kui kõrgetasemeliste praktikate põhikomplekti, mille te integreerite igasse arendustsüklisse, mida te juba kasutate, eesmärgiga käsitleda algpõhjuseid, et haavatavused ei kordu. Viige oma mäluturvalisuse reeglid sellesse olemasolevasse protsessi: uue koodi keelevalik, fuzzing CI-s, ebaturvaliste konstruktsioonide ülevaatuse värav. SSDF annab ostjatele ja tarnijatele ka ühise sõnavara, mis aitab, kui kliendi turvaküsimustik küsib mäluturvalisuse kohta.
Kodeerimise kontrollnimekirjade jaoks: OWASP projekt Secure Coding Practices Quick Reference Guide on arhiveeritud. Selle kontrollnimekirjad on kolinud OWASP Developer Guide'i, nii et kasutage seda versiooni, mitte aegunud PDF-i.
Kust alustada
- Eksportige loetelu kõigist C ja C++ komponentidest, sealhulgas vendored ja püsivara koodist, ning täitke ülaltoodud inventuuritabel. Piirake see kahe nädalaga.
- Märkige komponendid, mis loevad ebausaldusväärset sisendit, ja loetlege, millele igaüks kompromiteerimise korral ligi pääseb.
- Viige kolm kõige enam avatud komponenti eraldi madala õigusega protsessidesse või planeerige muudatus nimeliselt määratud vastutajaga.
- Kirjutage samadele komponentidele fuzz harnessid ja käivitage need CI-s. Vaadake krahhe üle iga nädal.
- Valige üks komponent ümberkirjutamiseks mäluturvalises keeles ning kehtestage keelereegel kogu uuele võrku suunatud koodile.
- Avaldage ühelehekülgne sisemine teekaart vastutajate ja tähtaegadega ning otsustage seejärel, mida klientidega jagate. Kui soovite välist kontrolli, saavad meie turvalise tarkvaraarenduse teenus ja penetratsioonitestimine inventuuri üle vaadata ning isoleeritud komponente testida.
