Stel: je laat een (verplichte) audit uitvoeren op je webomgeving en volgens die audit draait je besturingssysteem op een versie met CVE exploits die je omgeving erg kwetsbaar maken. Moet je dan in paniek naar je provider bellen om te eisen dat die meteen overschakelt naar de recentste versie? Bel je al je klanten om hen te waarschuwen dat hun data mogelijk te grabbel hebben gelegen? Bereid je een statement voor om je te excuseren voor alle ongemak? Of neem je gewoon met ons contact op om dit te bespreken?

Zo’n vaart hoeft het immers meestal niet te lopen. Meestal zit de fout eerder in de audit dan in je omgeving. Calrissia maakt immers gebruik van het zogeheten ‘backporting’ om de belangrijkste security patches en bug fixes tevoorzien in de huidige versie. Jammer genoeg wordt bij dergelijke audits niet gekeken naar sporen van backporting en blijft de conclusie dat de webomgeving elke minuut kan gehackt worden.

Backporting in praktijk

Wat is dat backporten precies en waarom wordt dit door vendors zoals Red Hat toegepast? Om dit uit te leggen gebruiken we een voorbeeld dat Red Hat zelf heeft uitgewerkt. In versie 6 van hun Red Hat Enterprise Linux zat versie 5.3 van scripttaal PHP, waarvoor na augustus 2014 geen nieuwe fixes meer werden gemaakt. Maar in oktober 2014 raakte een ‘buffer overflow’ bekend die die PHP-applicaties blootstelde aan hacking en misbruik van de applicatie. Deze werd door PHP dus niet automatisch opgelost, PHP voorzag enkel de uitweg van een upgrade naar 5.4.

Jammer genoeg is het vaak niet zo eenvoudig voor bedrijven om zulke upgrade uit te voeren. Vaak gaat dat gepaard met heel wat ‘backward compatibility issues’. Hierom hebben systeembeheerders doorgaans weinig tijd en zin om snel dergelijke upgrades uit te voeren. Tegelijk willen ze natuurlijk ook liever hun omgeving niet zomaar te grabbel gooien voor hackers en andere kwaadwillenden. Daarom werd het concept van backporting uitgewerkt.

Backporting gebeurt in drie fasen:

  • de security fixes identificeren en distilleren uit de nieuwe versie;
  • nagaan of deze fixes geen ongewenste neveneffecten opleveren voor de bestaande omgevingen
  • de fixes toepassen op de vorige versie(s)

Onder de audit-radar

Concreet is PHP 5.3 na backporting dus even goed beschermd als de volgende versies van de scripttaal. Maar bij een PCI-audit blijft dit backporting-proces vaak onder de radar. Als bij zulke audit enkel naar het versienummer van een component wordt gekeken, zal men er onterecht van uitgaan dat die component nog geen security fix voor dit lek heeft gehad. Red Hat probeert dit onder meer te ondervangen door voor elk lek een CVE-nummering te voorzien en daarnaar te verwijzen bij de beschrijving wanneer en hoe een probleem werd opgelost. Hierdoor wordt ook duidelijk dat dit los kan staan van een upgrade die al dan niet heeft plaatsgevonden. Klanten en auditors kunnen deze informatie raadplegen, of ze kunnen met OVAL-compatibele tools automatisch nagaan welke status elke kwetsbaarheid heeft en of hiervoor eventueel een backport is uitgevoerd.

Conclusie

Of je nu Red Hat draait of CentOS, en ongeacht de versie die je draait, het loont steeds de moeite om eerst even na te gaan bij je web hosting provider of je je echt zorgen moet maken. Meestal zal een backport je omgeving al beschermen nog voor je er zelfs maar over hebt gehoord. Als je auditor tools nodig heeft om voortaan zelf naar die backports op zoek te gaan, in plaats van hun klanten nodeloos te alarmeren, mag je hen steeds naar mij verwijzen voor advies.

Bij Calrissia worden alle patches meteen toegepast op alle omgevingen van alle klanten, en we bekijken nauwgezet hoe we dit het beste doen zonder impact op de draaiende omgeving. Het feit dat we het hierover niet hebben gehad, betekent enkel dat onze aanpak feilloos werkt, niet dat we er niet mee bezig waren.

Neem dus gerust met ons contact op. Niet alleen kunnen we jullie wellicht meteen geruststellen, het biedt ons ook de gelegenheid om nog eens te praten over security. Hadden we al gezegd dat we dit héél graag doen?