BLOG – Zolang we code blijven schrijven, blijven kwetsbaarheden in software bestaan. De aanpak van deze kwetsbaarheden betekent echter niet dat elke kwetsbaarheid moet worden gepatcht. Want zelfs als er zoiets als ‘honderd procent veilig‘ zou zijn, dan nog moet security zorgvuldig worden gebalanceerd met de vereisten voor innovatie en flexibiliteit – beiden voorwaarden voor bedrijfssucces. Bedrijven moeten begrijpen waar ze prioriteit moeten geven aan security en waar ze teams kunnen vrijmaken om zich op de kernactiviteiten te richten.
Het huidige dynamische en chaotische securitylandschap leidt tot meer kritische oordelen over de ‘zero risk’-benadering, waarbij de it-capaciteit volledig uitgaat naar het verhelpen van alle kwetsbaarheden, groot of klein. Een zero risk-architectuur is gericht op het elimineren van elke mogelijkheid voor systeemfalen of dataverlies, maar it moet zich wel afvragen of de innovatiekracht daaronder komt te lijden. Zou de organisatie haar concurrentievoordeel kunnen opofferen? Een hoge risicoaversie bij it kan bijvoorbeeld de ruimte beperken om te experimenteren met nieuwe technologieën die de bedrijfsefficiëntie kunnen bevorderen. Ook is er de kans dat de ontwikkeling van producten en diensten wordt vertraagd. Kijk ook naar de partners van je organisatie: blijf je bij risicoaversie een aantrekkelijke partner om mee samen te werken?
Om kwetsbaarheden in software effectief aan te pakken én hun concurrentievermogen te behouden, moeten it-teams uitgaan van risicobeheersing in plaats van pure risicovermijding.
Grondig begrip
Een risicogebaseerde aanpak betekent dat je met grondig begrip van de bedrijfsdoelen de securitymaatregelen afstemt op de werkelijke dreigingen en risico’s. Daar is een diepgravende risicoanalyse voor nodig, zodat je de impact, waarschijnlijkheid, dreigingsniveau, potentiële kosten én de noodzaak van beveiligingsmaatregelen kunt evalueren op de toegevoegde waarde.
Een uitgangspunt dat hier kan werken is: schaadt het niet, dan baat het niet. Moet je kwetsbaarheden met weinig risico wel verhelpen? Is het erg als er diep in je netwerk een olifantenpaadje open ligt richting een amper gebruikte service? Veelal is het beter om je aandacht te richten op grotere kwetsbaarheden die meer kritieke delen van je infrastructuur blootstellen aan aanvallen.
Is het erg als er diep in je netwerk een olifantenpaadje open ligt richting een amper gebruikte service?
Voor deze risicobeoordeling is wel een zekere mate van transparantie vereist. Dat wil zeggen dat het kristalhelder moet zijn welke kwetsbaarheden aanwezig zijn in je software supply chain en welke op de todolijst van je verschillende (toe)leveranciers staan om te verhelpen. Verbetering van de security van je supply chain betekent dat je onder meer devsecops-praktijken toepast, code en afhankelijkheden van derden op veilige wijze implementeert en zorgt dat security wordt ingebed in de gehele lifecycle van softwareontwikkeling. Er zijn oplossingen op de markt die vertrouwde cloudservices en voorgeschreven workflows samenbrengen om u te helpen uw systemen te beveiligen. Een vertrouwde software supply chain helpt organisaties kwaadaardige code buiten de deur te houden, hun ontwikkelomgevingen te beveiligen en continu de runtime-omgevingen te monitoren op dreigingen. Volledig inzicht in je aanvalsoppervlak en proactieve herstelmaatregelen helpen ervoor te zorgen je de bedrijfswaarde niet beïnvloedt door onnodige beveiligingsmaatregelen toe te passen.
Opensource
Dit is waar opensourcesoftware in uitblinkt, omdat het transparantie brengt. Waar commerciële leveranciers vaak onopgeloste kwetsbaarheden met een lager risico achterwege laten in hun changelogs, hebben opensourceprojecten doorgaans meer open communicatiekanalen en gedetailleerde changelogs die een completer beeld geven van de systeembeveiliging.
Bijna negentig procent van de bedrijfsleiders vindt opensourcesoftware even veilig of zelfs veiliger dan commerciële software. Het grootste voordeel is dat teams ‘goed geteste opensourcecode kunnen gebruiken voor eigen applicaties’. Andere voordelen zijn de kwaliteit van de documentatie en scanbaarheid van securitypatches en dat voor opensource kwetsbaarheden snel patches beschikbaar komen.
Waak er daarbij wel voor dat opensourceleveranciers gelaagde security hebben in de development pipelines én je organisatie kunnen ondersteunen om security in je eigen development workflows te implementeren. Eenvoudige maatregelen zoals een ondertekende Sales Bill of Materials van aangekochte software kunnen helpen om de veiligheid van componenten en eventuele tijdelijke afhankelijkheden helder te krijgen.
Cultuuromslag
Een balans tussen beveiliging, regelgeving en zakelijke doelen is cruciaal. Maar dat is makkelijker gezegd dan gedaan. Het vergt een cultuuromslag binnen organisaties. Open communicatie, samenwerking en persoonlijke interactie tussen teams zijn nodig om vertrouwen en effectieve ondersteuning te bevorderen, zodat securityprioriteiten beter zijn af te stemmen op de algemene bedrijfsdoelstellingen.
Doorlopende opleiding en training blijven van fundamenteel belang om die cultuuromslag te bewerkstelligen. Het blijft onverminderd belangrijk dat teams worden getraind in best practices, opkomende dreigingen en nieuwe technologieën. Naarmate organisaties migreren naar nieuwere technologieën en cloud-native ontwikkeling omarmen, is deze kennis broodnodig om een succesvolle overgang te garanderen zonder de veiligheid in gevaar te brengen.
Onvermijdelijk
Kwetsbaarheden in software zijn onvermijdelijk, maar organisaties kunnen risico’s minimaliseren door beveiligingsmaatregelen af te stemmen op werkelijke risico’s. Transparantie, samenwerking en voortdurende aanpassing zijn essentiële elementen in dit proces. Door een cultuur te stimuleren waarin open communicatie en educatie centraal staan, pakken organisaties kwetsbaarheden effectief aan en houden ze gelijke tred met veranderende bedreigingen en technologieën.
Kortom, behandel security als een constante, en niet als een blok aan het been of iets dat alleen belangrijk is in crisistijd.
Chris Jenkins is principal chief architect cybersecurity strategy & adoption bij Red Hat
bedrijf dit, bedrijf dat, bedrijfsdoelen..
Maar in de Opensource paragraaf lees ik dat je voor kwaliteit toch bij opensource moet zijn.
Aap uit de mouw dat het om opensourceLeveranciers gaat, maar dat je weer wel weer zelf moet nagaan wat voor security ze in hun “development pipelines” hebben en of die wel gelaagd genoeg is. Ja, daar ff tijd voor maken.. Misschien kun je een dure consultant zover krijgen dattie adviseert een extern bedrijfje in te huren dat de opensourceleverancier controleert 😛
Tenzij het om een wc-eend met rood hoedje gaat natuurlijk. Want als je die niet meer kan vertrouwen …
“Een balans tussen beveiliging, regelgeving en zakelijke doelen is cruciaal. Maar dat is makkelijker gezegd dan gedaan. Het vergt een cultuuromslag binnen organisaties. Open communicatie, samenwerking en persoonlijke interactie tussen teams zijn nodig om vertrouwen en effectieve ondersteuning te bevorderen, zodat securityprioriteiten beter zijn af te stemmen op de algemene bedrijfsdoelstellingen.”
<– heerlijke blaat, ik hoor al een dure consultant zich aanbieden 😉
Veel organisaties hebben een veiligheidsbeleid op basis van het risico management omdat impact de maatregelen bepaalt. Een olifantenpaadje richting een amper gebruikte service is als de ‘vergeten’ FTP service welke bij Hof van Twente voor de problemen zorgde. Dure consultant of niet, de rechter oordeelde in het nadeel van de gemeente want IT-leverancier was contractueel niet verantwoordelijk voor de beveiliging van het netwerk. Wat betreft cultuuromslag in het bestuurlijk ontzorgen is het wachten op Henri voor een doorlopende opleiding en training.