Een memory-safety roadmap is een plan met eigenaren en data, en u kunt er dit kwartaal een opstellen zonder het grootste deel van uw C- en C++-code aan te raken. De herschrijving komt later en beperkt zich tot de onderdelen die dat rechtvaardigen. Wat u nu nodig hebt, is een helder beeld van waar onveilige code zit, een manier om die in te perken en een vastlegging van wat u hebt besloten.
In The Case for Memory Safe Roadmaps beschrijft CISA hoe softwarefabrikanten kunnen overstappen op memory safe languages (MSL's) om memory-safety-kwetsbaarheden uit te bannen. CISA vraagt fabrikanten om roadmaps te publiceren, zodat klanten kunnen zien hoe zij de verantwoordelijkheid voor beveiligingsresultaten nemen, radicale transparantie betrachten en een top-downbenadering hanteren. Dat zijn Secure by Design-principes, en het document richt zich zowel op bestuurders als op engineers. Dat tweede publiek is belangrijk: een roadmap zonder sponsor blijft in een wiki liggen.
Wat de bronnen behandelen en wat niet
De samenvattingspagina van CISA noemt alleen de overgang naar MSL's en het opstellen en publiceren van een roadmap. De volledige inhoud wordt er niet getoond, dus we doen geen uitspraken over wat het document zegt over fuzzing of procesisolatie. Die twee stappen hieronder zijn onze eigen werkwijze voor de jaren tussen "we hebben nu C++" en "we hebben een veiligere taal in de onderdelen die ertoe doen". Beschouw ze als tijdelijke maatregelen, niet als vervanging van de roadmap.
De bronnen geven ook geen cijfers over hoeveel risico een bepaalde stap wegneemt. Die verzinnen wij niet. Meet het zelf, aan de hand van uw eigen crash- en kwetsbaarheidshistorie.
Stap 1: breng de onveilige code in kaart
U kunt niet prioriteren wat u niet hebt geïnventariseerd. Maak een tabel per component, niet per repository, want één repository bevat vaak zowel een onschuldig hulpprogramma als een netwerkparser.
| Veld | Waarom het ertoe doet |
|---|---|
| Taal en standaard | Laat zien wat wel en niet gemigreerd kan worden |
| Van buitenaf bereikbaar? | Netwerk, bestand, USB, serieel, updatekanaal |
| Verwerkt onvertrouwde invoer? | Bepaalt de prioriteit voor fuzzing en herschrijving |
| Met welke rechten draait het? | Bepaalt hoeveel isolatie helpt |
| Van derden of van ons? | Bepaalt wie het kan oplossen |
| Eigenaar en laatste inhoudelijke wijziging | Dode code kan vaak worden verwijderd |
Neem ook gevendorde bibliotheken en firmwarecomponenten mee. Vooral hardwareteams hebben vaak oude C-code in bootloaders, drivers en updatehandlers die al jaren niemand heeft geopend. Ook die componenten verdienen een rij.
Stap 2: isoleer wat u nog niet kunt vervangen
Vraag u bij elk component dat als bereikbaar is gemarkeerd en onvertrouwde invoer verwerkt af wat er gebeurt als het volledig gecompromitteerd raakt. Is het antwoord "alles", dan is dat uw eerste ontwerpwijziging. Verplaats de parser naar een eigen proces, verlaag de rechten en haal de toegang weg tot bestanden, sockets en sleutels die de parser niet nodig heeft.
Dit verhelpt de bug niet. Het beperkt wat de bug voor een aanvaller waard is. Dat sluit aan bij de doelstelling uit het Secure Software Development Framework (SP 800-218) van NIST: de mogelijke impact beperken van misbruik van kwetsbaarheden die u nog niet hebt gevonden.
Stap 3: fuzz de ingangspunten
Neem de componenten uit uw inventaris die onvertrouwde invoer verwerken en schrijf voor elk een fuzz harness. Draai de harnesses in CI met een tijdsbudget en bewaar het crashcorpus. Begin met bestandsformaten, protocolberichten en updatepakketten, want dat zijn de paden die een buitenstaander kan bereiken.
Bouw de fuzzing-binaries met de geheugenfoutdetectie van de compiler ingeschakeld, zodat een onopgemerkte overread een zichtbare fout wordt. Elke crash die u analyseert levert iets op wat de roadmap nodig heeft: bewijs over welke componenten een herschrijving verdienen. Vindt een harness na langdurig draaien niets, dan is ook dat bruikbaar, want dan kunt u dat component lager rangschikken.
Stap 4: kies een korte herschrijflijst
Gebruik de eerste drie stappen om kandidaten te kiezen. Een goede eerste herschrijving heeft de volgende eigenschappen:
- Het verwerkt onvertrouwde invoer.
- Het heeft een smalle interface, zodat het achter dezelfde API kan worden vervangen.
- Het heeft crashes opgeleverd bij fuzzing of kent een bughistorie.
- Het is klein genoeg voor één team om het in een of twee releasecycli af te ronden.
Laat stabiele, interne code die niet is blootgesteld in C of C++ staan en zeg dat ook in de roadmap. Het is eerlijk om bij een component "niet gepland, geïsoleerd, gefuzzd" te noteren, en klanten kunnen daar prima mee uit de voeten. Dit is onze interpretatie van radicale transparantie: u geeft uw standpunt weer en niet elke rij hoeft op een herschrijving uit te komen. De samenvatting van CISA noemt het principe, maar zegt niet wat het betekent voor componenten die in C of C++ blijven.
Nieuwe componenten zijn de goedkoopste plek om te beginnen. Beslis nu welke taal nieuwe, op het netwerk gerichte code gebruikt en leg dat vast in uw engineeringstandaarden.
Stap 5: leg het vast en koppel het aan uw proces
NIST beschrijft de SSDF als een kernset van hoogwaardige praktijken die u integreert in de ontwikkelcyclus die u al hanteert, met als doel de grondoorzaken aan te pakken zodat kwetsbaarheden niet terugkeren. Verwerk uw memory-safety-regels in dat bestaande proces: taalkeuze voor nieuwe code, fuzzing in CI en een reviewpoort voor onveilige constructies. De SSDF geeft afnemers en leveranciers bovendien een gemeenschappelijk vocabulaire, wat helpt wanneer de beveiligingsvragenlijst van een klant naar memory safety vraagt.
Voor checklists over veilig coderen is het project OWASP Secure Coding Practices Quick Reference Guide gearchiveerd. De checklists zijn verhuisd naar de OWASP Developer Guide, gebruik dus die versie in plaats van een verouderde pdf.
Waar u kunt beginnen
- Exporteer een lijst van alle C- en C++-componenten, inclusief gevendorde code en firmware, en vul de inventaristabel hierboven in. Geef uzelf daarvoor maximaal twee weken.
- Markeer de componenten die onvertrouwde invoer lezen en noteer waartoe elk component toegang heeft als het gecompromitteerd raakt.
- Zet de drie meest blootgestelde componenten in aparte processen met lage rechten, of plan die wijziging in met een benoemde eigenaar.
- Schrijf fuzz harnesses voor diezelfde componenten en draai ze in CI. Bekijk de crashes wekelijks.
- Kies één component voor een herschrijving in een memory safe language en stel een taalregel vast voor alle nieuwe, op het netwerk gerichte code.
- Publiceer een interne roadmap van één pagina met eigenaren en data en bepaal daarna wat u met klanten deelt. Wilt u een onafhankelijke toets, dan kunnen onze dienst voor veilige softwareontwikkeling en penetratietesten de inventaris beoordelen en de geïsoleerde componenten testen.
