Wat is backporting? Werking en proces

Lees meer over backporting en kwetsbaarheden in softwarebeveiliging. Ontdek hoe backporting-fixes uit nieuwere versies legacy-systemen kunnen beschermen zonder volledige upgrades, waardoor de algehele beveiliging wordt verbeterd.

De afgelopen jaren is het aantal gemelde Common Vulnerabilities and Exposures (CVE's) gestaag toegenomen. Alleen al in de eerste helft van 2024 werden er 22.254 CVE's gemeld, maar liefst 30% meer dan de 17.114 CVE's die in 2023 werden geregistreerd. Aangezien deze kwetsbaarheden, indien misbruikt, schadelijke financiële en reputatieschade tot gevolg hebben, hebben bedrijven maar één optie: kwetsbaarheden onmiddellijk patchen. Maar dat is makkelijker gezegd dan gedaan. Bij verouderde systemen is het soms gewoonweg onpraktisch om kwetsbare versies te upgraden naar nieuwere versies met de beveiligingspatches. Hier komt backporting om de hoek kijken.

Stel je voor dat je al jaren een antieke auto hebt. Plotseling beginnen de motor en de wielen problemen te geven. Het slechte nieuws is dat het een heel oud model is, dus u kunt geen onderdelen vinden. Maar u wilt de auto ook niet vervangen door een nieuwer model. In plaats daarvan laat u uw monteur compatibele onderdelen van een nieuw model verzamelen en deze op uw antieke auto monteren. Probleem opgelost!

Backporting is vergelijkbaar met dit voorbeeld; het betekent dat patches uit de meest recente softwareversie worden aangepast om problemen in verouderde systemen op te lossen. In dit artikel gaan we dieper in op backporting en belichten we het belang ervan, gebruiksscenario's, bijbehorende kwetsbaarheden en best practices.

Wat is backporting?

Backporting is het overzetten van beveiligingsoplossingen of nieuwe functies uit nieuwere softwareversies naar oudere versies.

Waarom is backporting belangrijk? Backporting is een centraal onderdeel van kwetsbaarheidsbeheer en is noodzakelijk wanneer het upgraden van kwetsbare softwareversies problematisch is.

Bekijk dit praktijkvoorbeeld eens: Red Hat bracht Red Hat Linux 8.0 op de markt. met Apache HTTP Server versie 2.0.40. Kort daarna werden er beveiligingskwetsbaarheden ontdekt in de oude Apache-versie en werd er een nieuwe versie uitgebracht: 2.0.43.

Hoewel de nieuwe versie deze bugs verholpen had, bevatte deze ook codewijzigingen die de upstream-software incompatibel zouden maken met tal van downstream-implementaties die ervan afhankelijk waren. In plaats van de nieuwe versie in zijn geheel toe te passen, heeft Red Hat de patch dus teruggeport door de relevante codefragmenten te nemen en deze aan te passen aan de oudere versie.

In wezen betekent backporting dat u zelf toegang krijgt tot de broncode van een softwareversie en deze aanpast, of dat u een backported upstream-versie krijgt van uw softwaredistributeur, zoals in het bovenstaande voorbeeld van Red Hat. Hier volgen enkele veelvoorkomende scenario's voor backporting:

• Legacy-systemen: Ondernemingen die afhankelijk zijn van legacy-software staan voor een unieke uitdaging: bestaande systemen zijn vaak niet compatibel met de nieuwste updates. Backporting lost dit probleem op door prestatie- en beveiligingsproblemen in legacy-systemen te verhelpen zonder dat volledige vervanging of refactoring nodig is.
• Naleving van regelgeving: Voor organisaties die te maken hebben met beschermde gezondheidsinformatie (PHI), betaalkaartinformatie (PCI) en persoonlijk identificeerbare informatie (PII) van klanten, is het beschermen van gevoelige gegevens in overeenstemming met regelgevingsnormen zoals HIPAA, GDPR en PCI DSS een prioriteit. Backporting stelt deze ondernemingen in staat om aan de nalevingsvereisten te voldoen zonder het gedoe van softwareversiebeheer.
• Beperkte middelen: Waar upgrades aanzienlijke personele, financiële en systeembronnen zouden kosten die veel bedrijven zich simpelweg niet kunnen veroorloven, biedt backporting een bronnenefficiënt alternatief.

Verschillen tussen backporting, patchen en upgraden

Backporting, patching en upgrading zijn analoge concepten die vergelijkbare functies vervullen, maar via verschillende methoden. Hier volgt een overzicht van de verschillen.

Parameters	Backporting	Patching	Upgraden
Functie	Retrofits kritieke patches in nieuwe softwareversies naar oudere versies	Past beveiligingsoplossingen toe op huidige softwareversies om geïsoleerde kwetsbaarheden op te lossen	Overstapt van een oudere softwareversie naar een nieuwe, uitgerust met verbeterde functies en beveiligingspatches
Doel	Voornamelijk gericht op het oplossen van beveiligingsproblemen	Het oplossen van beveiligings- en prestatieproblemen	Het bieden van allesomvattende verbeteringen
Uitdaging	Vereist uitgebreide technische expertise	Kan leiden tot instabiliteit of nieuwe risico's met zich meebrengen als het niet goed wordt getest	Kan compatibiliteitsproblemen met downstreamsoftware veroorzaken

Hoe werkt backporting?

Het backportingproces omvat een reeks stappen:

Stap 1: Identificeer de kwetsbaarheid waarvoor u beveiligingsoplossingen wilt backporten. Dit kan door middel van beveiligingscontroles die worden uitgevoerd door interne teams of beveiligingsadviezen die op internet worden gepubliceerd.

Stap 2: Zoek de nieuwe softwareversie die het probleem oplost.

Stap 3: Isoleer de oplossing van andere wijzigingen in de nieuwe softwareversie door de benodigde codefragmenten te extraheren.

Stap 4: Pas de geïsoleerde oplossing aan het oude systeem aan.

Stap 5: Test in een gecontroleerde omgeving om er zeker van te zijn dat de kwetsbaarheid daadwerkelijk wordt verholpen, zonder dat dit leidt tot prestatie- of beveiligingsproblemen of andere ongewenste effecten, zoals het wijzigen van eerdere functionaliteit.

Stap 6: Backport de fixes naar het oude systeem, lever ze aan de productie en houd ze continu in de gaten.

Kwetsbaarheden in verband met backporting

Hoewel backporting een cruciale reddingsboei is voor organisaties die bepaalde software niet kunnen upgraden, is het niet zonder risico's. Een groot risico van backporting is dat oudere systemen mogelijk geen native ondersteuning bieden voor nieuwere beveiligingsframeworks. Backported fixes kunnen dus uiteindelijk backporting-kwetsbaarheden introduceren terwijl u andere kwetsbaarheden probeert te verhelpen.

Wat zijn backporting-kwetsbaarheden?

Backporting-kwetsbaarheden zijn risico's die voortkomen uit het aanpassen van beveiligingspatches die zijn ontworpen voor moderne systemen aan oudere versies, wat mogelijk kan leiden tot onvoorziene neveneffecten.

Soorten kwetsbaarheden door backporting

Wanneer er grote verschillen zijn in de architectuur of afhankelijkheden tussen de nieuwe en oude softwareversies, kan backporting de volgende soorten kwetsbaarheden introduceren:

 1. Beveiligingskwetsbaarheden

Beveiligingsoplossingen in nieuwere softwareversies zijn vaak gebaseerd op beveiligingsparadigma's die niet in oudere versies te vinden zijn. Als u deze oplossingen backport, moet u oppassen dat u geen nieuwe backporting-kwetsbaarheden introduceert of oude kwetsbaarheden onjuist aanpakt.

Bijvoorbeeld: heeft Microsoft onlangs een update uitgebracht voor een kwetsbaarheid in .NET voor het uitvoeren van externe code (RCE) (CVE-2024-38229). Hoewel deze update effectief is in .NET 8.0- en 9.0-systemen, heeft deze mogelijk niet het gewenste effect als deze wordt teruggeport naar .NET 6.0. Dit komt doordat de HTTP/3-stream, waarop de kwetsbaarheid zich richt, in versie 6.0 alleen experimenteel is.

2. Compatibiliteitsproblemen

Bij het terugporten zijn er veel componenten waarmee rekening moet worden gehouden, waaronder afhankelijkheden, API's, frameworks en bibliotheken, besturingssystemen, gesplitste applicaties en meer. Gezien deze lange lijst is het een uitdaging om ervoor te zorgen dat teruggeporteerde patches volledig integreren met alle componenten. Wanneer de architectuur van legacy-systemen simpelweg niet compatibel is met nieuwere systemen, kunnen uitgebreide aanpassingen aan de patch nodig zijn.

Nieuwere softwareversies maken bijvoorbeeld gebruik van moderne softwareontwikkelingskits (SDK's) zoals Kubernetes SDK's die mogelijk niet bestaan in legacy-software. Backporting van patches in dergelijke gevallen zou vereisen dat ontwikkelaars de codefragmenten (die de patch bevatten) herschrijven of ingewikkelde workarounds installeren, die ook compatibel moeten zijn.

3. Prestatieverlies

Nieuwere softwareversies zijn vaak ontworpen met het oog op snelheid en veiligheid, waardoor ze meer resources kunnen verbruiken. Het backporten van patches die op deze manier zijn ontworpen naar oudere, tragere systemen kan de verwerkingscapaciteit van de systemen overbelasten, wat kan leiden tot tragere responstijden, fouten of, erger nog, systeemcrashes.

Risico's in verband met het terugkoppelen van kwetsbaarheden

• Beveiligingsrisico's: Onjuist teruggekoppelde patches kunnen kwetsbaarheden onopgelost laten of nieuwe kwetsbaarheden introduceren.
• Operationele risico's: Het toewijzen van middelen voor backporting kan leiden tot mogelijke downtime of onderbrekingen van de dienstverlening.
• Compliance-risico's: Onvoldoende backporting kan leiden tot niet-naleving van beveiligingsnormen.

Hoe backported wijzigingen te testen en te valideren

Het testen en valideren van backported patches voordat ze worden verzonden, is van cruciaal belang voor een veilig en effectief backportingproces. Dit omvat:

• Het gebruik van oplossingen voor kwetsbaarheidsbeheer om kwetsbaarheden op te sporen die niet volledig zijn opgelost door het backportingproces.
• Gebruik van kwetsbaarheidsscanners om vast te stellen dat het backportingproces geen nieuwe kwetsbaarheden heeft geïntroduceerd.

• Gebruik van regressietesttools om te controleren of de patches correct worden geïntegreerd zonder de bestaande functionaliteit negatief te beïnvloeden.

• Penetratietesters inzetten om backported patches verder te testen op mogelijke beveiligingskwetsbaarheden.

Uitdagingen van backporting

Hoewel backporting een effectieve manier is om kwetsbaarheden in verouderde systemen die niet gemakkelijk kunnen worden vervangen op te lossen, kunnen bedrijven met de volgende uitdagingen worden geconfronteerd:

#1. Complexiteit

Wanneer er compatibiliteitsproblemen zijn, vereist backporting uitgebreide herschrijvingen van de code, wat meestal een tijdrovend proces is. Bovendien moeten bedrijven hiervoor zeer gespecialiseerde ingenieurs en tools inzetten.

#2. Onopgeloste risico's

Backporting lost het probleem mogelijk niet volledig op, zelfs als het compatibel is. Dit kan het geval zijn als de kwetsbaarheid in het architecturale ontwerp zelf ligt. In een dergelijk geval kan backporting bedrijven een vals gevoel van veiligheid geven totdat de kwetsbaarheid wordt misbruikt.

#3. Verwarring over CVE-nummering

Veel beveiligingsoplossingen detecteren kwetsbaarheden uitsluitend door ze te correleren met CVE-identificatienummers in kwetsbaarheidsdatabases. Het komt dan ook vaak voor dat dergelijke tools softwareversies continu als kwetsbaar markeren, zelfs nadat backporting de kwetsbaarheid volledig heeft opgelost, wat leidt tot valse positieven.

#4. Slechte documentatie

Organisaties zijn afhankelijk van serviceproviders voor softwarepatches voor besturingssystemen, frameworks, bibliotheken en meer. In gevallen waarin upgrades niet haalbaar zijn, voeren deze providers backports uit. Als dit niet duidelijk wordt gedocumenteerd voor elke uitgebrachte beveiligingsfix, kunnen gebruikers onbedoeld aannemen dat er een upgrade is uitgevoerd in plaats van een backport.

Hetzelfde geldt voor slecht gedocumenteerde interne backportingprocessen. Slechte documentatie zorgt ervoor dat gebruikers niet begrijpen waarom ze na een "update" nog steeds een oudere versie hebben. Het kan ook beveiligingsrisico's met zich meebrengen als gebruikers de backported wijzigingen niet op de juiste manier toepassen.

Best practices voor het beperken van backporting-kwetsbaarheden

Hier zijn de 7 belangrijkste best practices voor backporting die u kunt implementeren voor een kwetsbaarheidsvrij backportingproces.

1. Beoordeel de backportingbehoeften: Voordat u besluit tot backporting, moet u er zeker van zijn dat dit de meest effectieve aanpak is om de kwetsbaarheid op te lossen. Weeg dit af tegen een grondig onderzoek naar de mate van prestatieverlies en operationele complexiteit die u zult ondervinden als u kiest voor backporting of upgraden.
2. Volg strenge testprotocollen: Test backported fixes voor beveiligingskwetsbaarheden en prestatieproblemen grondig voordat u ze verzendt. Robuuste tests – in gecontroleerde omgevingen – zorgen ervoor dat bestaande kwetsbaarheden worden opgelost en dat het backportingproces geen nieuwe kwetsbaarheden introduceert.
3. Voer grondige risicobeoordelingen uit: Zorg ervoor dat de potentiële risico's of uitdagingen van backporting ruimschoots worden gecompenseerd door de voordelen op het gebied van beveiliging, bedrijfsvoering en compliance voor uw onderneming.
4. Houd uitgebreide documentatie bij: Dit is cruciaal voor het bijhouden van backported wijzigingen in de loop van de tijd en het creëren van gedetailleerde compliance-audittrails. Het is ook van cruciaal belang voor toekomstige debugging en analyse van de onderliggende oorzaak.
5. Gebruik versiebeheersystemen (VCS): VCS zoals Git en Azure DevOps zijn geweldige tools voor het bijhouden van teruggeporteerde wijzigingen en het handhaven van de integriteit van de code. Ze bieden versiegeschiedenissen die van pas komen als er instabiliteitsproblemen zijn met teruggeporteerde versies en er behoefte is om terug te keren naar een eerdere stabiele versie.
6. Zorg voor processen voor wijzigingsbeheer: Dit omvat het grondig controleren en beoordelen van teruggeporteerde patches voordat ze worden verzonden, het toepassen van teruggeporteerde wijzigingen zonder de app-functies te verstoren, en het continu monitoren van de IT-stack op prestatieverlies of andere mogelijke problemen nadat backporting is geïmplementeerd.
7. Gebruik de juiste tools: De juiste tools voor kwetsbaarheidsbeheer en beveiligingstesten kunnen een enorm verschil maken in hoe soepel uw backportingproces verloopt.

Veelvoorkomende gebruiksscenario's voor backporting

Het meest voorkomende gebruiksscenario voor backporting is verouderde software waar volledige upgrades niet haalbaar zijn. Dit komt vooral veel voor in de gezondheidszorg, de financiële sector en andere sectoren waar verouderde systemen essentieel zijn voor de dagelijkse bedrijfsvoering en waar elke poging om ze te upgraden zou leiden tot enorme verstoringen van de dienstverlening. Andere toepassingen voor backporting zijn onder meer:

• Het beveiligen van bedrijfskritische productiesystemen waar hoge beschikbaarheid essentieel is, bijvoorbeeld de mainframes die vaak door banken worden gebruikt om grote hoeveelheden verkeer te verwerken en snelle gegevensverwerking mogelijk te maken

• Het beveiligen van langetermijnondersteuningsversies (LTS) van open-sourceprojecten, bijvoorbeeld de Linux-kernel LTS, die vaak door cloudserviceproviders wordt gebruikt om stabiliteit te garanderen en versiecompatibiliteit in hybride omgevingen te vergemakkelijken.

• Voldoen aan compliance-eisen in sterk gereguleerde sectoren zoals de financiële sector en de gezondheidszorg. Door bijvoorbeeld patches te backporten, kunnen ziekenhuizen blijven voldoen aan wetgeving op het gebied van gegevensbescherming, zoals HIPAA, zonder te maken te krijgen met de aanzienlijke serviceonderbrekingen die gepaard gaan met upgrades.

Conclusie

Backporting kan veel problemen verhelpen, maar kan ook nieuwe uitdagingen met zich meebrengen. U bent veilig als u een AI-oplossing voor bedreigingsmonitoring gebruikt om bestaande kwetsbaarheden of potentiële kwetsbaarheden die zich kunnen voordoen aan te pakken. U kunt beveiligingspatches van nieuwere releases naar oudere releases backporten om kwetsbaarheden te verhelpen zonder verstorende upgrades te veroorzaken.

Succesvolle backporting vereist uitgebreide tests, volledige documentatie, een correcte risicoanalyse en gespecialiseerde beveiligingstools om het proces te ondersteunen.

"

FAQs

Wat is het verschil tussen backporting en het upgraden van software?

Backporting houdt in dat beveiligingspatches in recente softwareversies worden geïsoleerd en toegepast op oudere versies om kritieke beveiligingskwetsbaarheden op te lossen. Upgraden houdt daarentegen in dat nieuwe softwareversies worden geïmplementeerd die beveiligingspatches, bugfixes, nieuwe functies en andere verbeteringen bevatten.

Wanneer moeten organisaties backporting overwegen in plaats van upgraden?

Organisaties moeten backporting verkiezen boven upgraden wanneer systemen hoge uptime-eisen hebben, upgrades kunnen leiden tot ernstige incompatibiliteitsproblemen, of upgrades gewoonweg te tijdrovend en te veel middelen vergen om haalbaar te zijn.

Wat zijn de veelvoorkomende uitdagingen tijdens het backportingproces?

Veelvoorkomende uitdagingen bij backporting zijn onder meer complexiteit waarbij uitgebreide aanpassingen nodig zijn, slecht gedocumenteerde backported wijzigingen en onjuist opgeloste kwetsbaarheden.

Welke rol spelen ontwikkelingsteams bij het backporten van kwetsbaarheden?

Ontwikkelingsteams spelen een belangrijke rol bij het backporten van kwetsbaarheden. Eerst moeten ze – in samenwerking met beveiligingsteams – kritieke kwetsbaarheden in oudere softwareversies identificeren. Vervolgens moeten ontwikkelaars codecorrecties in nieuwe versies isoleren en aanpassen aan de oudere systemen.