Uit de praktijk
Een softwareleverancier wil een update uitvoeren. De nieuwe programmabestanden worden geplaatst, maar de applicatie start niet direct. De beveiligingssoftware houdt de gewijzigde bestanden tijdelijk tegen. Na enige tijd werkt alles alsnog, maar voor de leverancier is de situatie onwenselijk. Zeker wanneer een dringende bugfix moet worden geïnstalleerd, wil hij niet afhankelijk zijn van een beveiligingscontrole.
De leverancier stelt daarom een begrijpelijke vraag: kan de installatiemap van de applicatie niet worden uitgesloten van de beveiliging? Het lijkt een praktische oplossing voor een vervelend probleem. Maar achter die vraag schuilt een belangrijk beveiligingsrisico. Want wat gebeurt er als juist via die vertrouwde softwareleverancier een geïnfecteerd bestand wordt verspreid?
Een vertrouwde leverancier is niet hetzelfde als vertrouwde software
De situatie speelde bij een organisatie waar een externe leverancier verantwoordelijk is voor een bedrijfsapplicatie. Om onderhoud uit te voeren, moet deze leverancier regelmatig programmabestanden vervangen en services opnieuw starten. De IT-omgeving wordt door Malenco beveiligd met een oplossing die onbekende of gewijzigde programmabestanden niet zonder meer laat uitvoeren. Nieuwe versies worden eerst beoordeeld voordat ze worden toegelaten.
Toen de leverancier tijdens onderhoud bestanden verving, werd het starten van een service tijdelijk geblokkeerd. De leverancier vermoedde dat de beveiligingssoftware hiervan de oorzaak was en vroeg of de betreffende applicatiemap als uitzondering kon worden ingesteld. Vanuit zijn perspectief was dat logisch. Een softwareleverancier moet onderhoud kunnen uitvoeren en bij problemen snel kunnen handelen. Een beveiligingsmaatregel die onverwacht een update tegenhoudt, kan dan als hinderlijk worden ervaren.
Toch zou het uitsluiten van de volledige applicatiemap een wezenlijk deel van de bescherming wegnemen. Het probleem is namelijk niet dat Malenco de leverancier wantrouwt. Het probleem is dat niemand op basis van alleen de herkomst of bestandsnaam kan garanderen dat een nieuw programmabestand veilig is.
Ook een betrouwbare leverancier kan worden getroffen door een beveiligingsincident. Wanneer aanvallers toegang krijgen tot een ontwikkelomgeving, een distributieproces of een software-update, kunnen geïnfecteerde bestanden worden verspreid via een kanaal dat voor klanten volkomen legitiem lijkt. Maar het risico kan ook binnen de IT-omgeving van de klant zelf ontstaan. Als aanvallers daar toegang krijgen en voldoende rechten hebben, kunnen zij een bestaand programmabestand in de applicatiemap vervangen door een geïnfecteerde versie. De bestandsnaam en locatie kunnen daarbij hetzelfde blijven, terwijl de inhoud is gewijzigd. Een algemene uitzondering voor die map kan er dan voor zorgen dat ook het vervangen bestand buiten de betreffende beveiligingscontrole valt. Juist daarom moet ook software van vertrouwde leveranciers gecontroleerd kunnen worden, ongeacht of een wijziging via de leverancier of binnen de omgeving van de klant plaatsvindt.
Waarom een nieuwe versie opnieuw beoordeeld wordt
De gebruikte beveiligingsoplossing werkt volgens een zero-trustbenadering voor het uitvoeren van applicaties. Daarbij wordt niet uitsluitend gekeken naar de naam van een programma of de leverancier ervan, maar naar het specifieke bestand dat wordt uitgevoerd. Een nieuwe versie van een programma is technisch een ander bestand dan de vorige versie. Zelfs wanneer beide bestanden dezelfde naam hebben en van dezelfde leverancier afkomstig lijken, betekent dat niet automatisch dat de nieuwe versie veilig is. De beveiligingsoplossing kan daarom een gewijzigd bestand tijdelijk blokkeren totdat het is geclassificeerd. Die beoordeling helpt voorkomen dat onbekende of mogelijk schadelijke software direct wordt uitgevoerd.
Dat is geen theoretisch risico. Bij bekende aanvallen op de softwaretoeleveringsketen zijn eerder besmette updates verspreid via vertrouwde softwareproducten. De gebruiker dacht een normale update te installeren, terwijl de aanvaller daarmee juist toegang tot systemen probeerde te verkrijgen.
Een algemene uitzondering voor een applicatiemap zou deze controle grotendeels omzeilen. Nieuwe of gewijzigde bestanden op die locatie zouden dan minder streng worden beoordeeld, ongeacht hoe ze daar terechtkomen. Daarmee wordt een praktische oplossing voor het updateproces tegelijkertijd een potentiële zwakke plek in de beveiliging.
Beveiliging mag geen onverwachte hindernis worden
Dat betekent niet dat een leverancier maar moet afwachten totdat een beveiligingscontrole is afgerond. De leverancier wees er in de correspondentie terecht op dat vertraging bij het installeren van bugfixes ongewenst kan zijn. Wanneer een bedrijfsapplicatie niet goed functioneert, kan het noodzakelijk zijn om snel een nieuwe versie uit te rollen.
Malenco heeft daarom niet alleen uitgelegd waarom de beveiligingsmaatregel noodzakelijk is, maar ook hoe onderhoud binnen dat beleid werkbaar kan blijven. De afspraak is dat de leverancier vooraf contact opneemt wanneer nieuwe programmabestanden worden geïnstalleerd. Malenco kan zich daarop voorbereiden en de nieuwe versies gericht vrijgeven. Zo hoeft de leverancier tijdens gepland onderhoud niet onnodig op een classificatieproces te wachten.
De beveiliging blijft intact, terwijl de werkzaamheden beter op elkaar worden afgestemd. Dit vraagt om iets meer voorbereiding en communicatie. Maar het voorkomt dat tijdsdruk bij een softwarewijziging leidt tot een permanente beveiligingsuitzondering.
De werkelijke vraag is wie de regie heeft
Deze situatie laat zien dat beveiliging niet alleen een technische aangelegenheid is. Het gaat ook over verantwoordelijkheden en afspraken tussen partijen. Een applicatieleverancier is verantwoordelijk voor het functioneren en onderhouden van zijn software. De IT-beheerder moet tegelijkertijd bewaken dat wijzigingen geen onnodige risico's introduceren in de IT-omgeving van de klant. Die belangen hoeven elkaar niet tegen te spreken. Ze moeten alleen goed op elkaar worden afgestemd.
Wanneer een leverancier zelfstandig beveiligingsuitzonderingen kan laten aanbrengen, bestaat het risico dat de bescherming van de omgeving geleidelijk wordt uitgehold. Iedere uitzondering heeft immers een begrijpelijke aanleiding: een update die niet werkt, een applicatie die vertraagt of een onderhoudsvenster dat onder druk staat. Afzonderlijk lijken zulke verzoeken vaak redelijk. Maar gezamenlijk kunnen ze leiden tot een omgeving waarin steeds minder controle bestaat over welke software wordt uitgevoerd.
Goed IT-beheer betekent daarom dat iemand het overzicht bewaart, de risico's beoordeelt en waar nodig alternatieven organiseert. Niet om leveranciers het werk moeilijk te maken, maar om te zorgen dat hun werkzaamheden veilig kunnen plaatsvinden.
Wat deze situatie ons leert
In deze praktijkcase was de eenvoudigste oplossing om een uitzondering toe te voegen aan de beveiligingssoftware. Daarmee zou het directe probleem voor de leverancier waarschijnlijk zijn verdwenen. Malenco koos ervoor het afgesproken beveiligingsbeleid te handhaven en de samenwerking rond software-updates beter te organiseren.
Dat is een belangrijk onderscheid. Een beveiligingsoplossing aanschaffen en installeren is één ding. Er vervolgens voor zorgen dat die bescherming overeind blijft wanneer leveranciers, applicaties en bedrijfsprocessen veranderen, vraagt om actief beheer en duidelijke regie. Voor ondernemers is juist dat laatste van belang. Zij moeten erop kunnen vertrouwen dat hun applicaties beschikbaar blijven, maar ook dat de beveiliging niet bij iedere praktische hindernis terzijde wordt geschoven.
Goed IT-beheer betekent niet dat beveiliging en werkbaarheid tegenover elkaar staan. Het betekent dat iemand verantwoordelijkheid neemt om beide te organiseren.
