Supply Chain Attacks: als je leverancier het aanvalspunt wordt

Bij cybersecurity denken we vaak aan onze eigen systemen. Firewalls, Endpoint Detection and Response (EDR), Multi Factor Authentication (MFA), patchmanagement en sterke wachtwoorden. Maar wat gebeurt er als de aanvaller helemaal niet rechtstreeks op jouw systemen mikt? Wat als hij eerst een leverancier aanvalt?
Dat is het idee achter een supply chain attack. Een aanvaller compromitteert een leverancier, softwarepakket, ontwikkelaar, updatekanaal of andere schakel waarvan meerdere organisaties afhankelijk zijn. Via die vertrouwde schakel kan de aanvaller vervolgens slachtoffers bereiken.
Een voorbeeld van zo’n supply chain-incident is de SolarWinds hack. Daarbij hadden aanvallers software van een leverancier aangepast. De besmette software werd daarna door klanten gedownload en installeerde naast de legitieme software een extra kwaadaardige functionaliteit. Duizenden organisaties werden hierdoor geraakt.
Dat maakt supply chain attacks bijzonder interessant voor aanvallers. Een enkele succesvolle aanval kan toegang geven tot veel organisaties tegelijk.
Hoe ziet zo'n aanval eruit?
Er zijn verschillende manieren waarop een supply chain-aanval kan plaatsvinden.
Een aanvaller kan bijvoorbeeld het account van een softwareontwikkelaar overnemen en vervolgens ongemerkt kwaadaardige code toevoegen voordat een nieuwe versie wordt uitgebracht.
Een andere mogelijkheid is het compromitteren van de buildomgeving. Zelfs als de oorspronkelijke broncode veilig is, kan tijdens het buildproces, wanneer de software automatisch wordt samengesteld tot een installatiebestand, alsnog kwaadaardige code aan het eindproduct worden toegevoegd. Ontwikkelaars kunnen dan naar de broncode kijken en niets verdachts zien, terwijl het uiteindelijke product toch besmet is.
Waarom is dit zo gevaarlijk?
Schaal
Stel dat een aanvaller één leverancier compromitteert. Die leverancier heeft misschien honderden of duizenden klanten. Een kwaadaardige update kan vervolgens bij een groot deel van die klanten terechtkomen.
NCSC omschrijft precies dit probleem bij software supply chains. Automatisering, vertrouwen en schaal kunnen ervoor zorgen dat kwaadaardige code zich snel verspreidt voordat organisaties begrijpen wat er gebeurt.
Vertrouwen
Een organisatie kan haar eigen systemen uitstekend beveiligen. Maar als een vertrouwde leverancier wordt gehackt en een kwaadaardige update naar klanten stuurt, kan die beveiliging worden omzeild.
Securitysoftware kan alarm slaan wanneer een onbekend programma verbinding probeert te maken met een server. Een legitieme software-update ligt anders. Die update heeft vaak een geldig certificaat, komt van een bekende leverancier en wordt door beheertools automatisch geïnstalleerd. De gebruiker ziet immers geen verdachte download. Er verschijnt een normale update van software die al vertrouwd wordt.
Zichtbaarheid
Een derde probleem is zichtbaarheid. Organisaties weten lang niet altijd precies welke softwarecomponenten in hun omgeving aanwezig zijn. Een applicatie kan tientallen of honderden dependencies hebben. Daar kunnen weer andere dependencies onder zitten.
Hoe verdedig je je tegen een aanval via de keten?
Je kunt een leverancier nooit volledig vertrouwen. Je kunt het risico wel kleiner maken.
Begin met zichtbaarheid. Welke leveranciers, applicaties, packages en dependencies zijn daadwerkelijk onderdeel van je omgeving?
Kijk daarna naar updates en wijzigingen. Automatische updates zijn handig, maar een volledig automatische keten kan een probleem worden wanneer een vertrouwde bron wordt gecompromitteerd.
Bescherm ontwikkelaarsaccounts met MFA, beperk tokens en rechten, beveilig CI/CD-omgevingen en monitor onverwachte wijzigingen in repositories en buildprocessen.
Kijk ook verder dan je eigen organisatie. Vraag leveranciers hoe zij software bouwen, hoe zij toegang beschermen en hoe zij omgaan met incidenten. Een supply chain attack laat namelijk iets ongemakkelijks zien. Je beveiliging stopt niet bij je eigen firewall. Je organisatie is onderdeel van een keten. En die keten is maar zo sterk als de schakels die je niet zelf beheert.
