Afgelopen week deed het Nationaal Cyber Security Centrum (NCSC) een herhaalde oproep om Microsoft Exchange-servers te updaten. Veel servers blijken nog kwetsbaar voor misbruik. Lokale oplossingen zijn nu eenmaal lastiger te patchen dan in de cloud. Tijd voor uniforme policies op elk platform?
Ondanks eerdere oproepen van het NCSC zijn in veel organisaties de door Microsoft beschikbaar gestelde beveiligingsupdates niet geïnstalleerd. Het risico op misbruik is groot, zeker doordat criminelen drie aanvalstechnieken hebben: ProxyShell, ProxyOracle en ProxyToken. Door ze te combineren is het mogelijk om kwetsbare Exchange-servers op afstand over te nemen.
Laat dit een wake-up call zijn voor organisaties in alle sectoren, stelt Wim van Campen, vice president EMEA bij it-beveiligingsbedrijf Lookout. Volgens hem is het de verantwoordelijkheid van de organisaties zelf om deze kwetsbaarheden te patchen. ‘En juist daarin schuilt het probleem. Als dit een cloud service was geweest, dan zouden de benodigde patches door de cloud provider geïmplementeerd worden.’
‘It- en securityteams hebben een manier nodig om uniforme policies voor databescherming toe te passen op ieder systeem en platform, zowel on-premises als in de cloud. Op dit moment zijn er nog veel verschillen in de wijze waarop deze verschillende omgevingen worden beveiligd.’ Volgens Van Campen kan dit een negatieve impact hebben op de totale beveiliging van een organisatie.
Discussieer mee!
Wat vindt u? Waarom verschillen de policies voor databescherming op de verschillende systemen en platformen, lokaal en in de cloud? Hoe kun je deze verschillen opheffen? En: los je daarmee het probleem op van de ongenode gasten op je servers?
Hmmm wat nu als MS exchange patches elke dag automatisch zonder reboot en risico van interruptie van de dienst doorgevoerd zouden kunnen worden… utopie? als ik mijn ervaringen met security updates bij RHEL er tegenover zet misschien toch niet zo. Niet dat ik hiermee een open/closed source flame wil starten, ik wil namelijk betrouwbare automatische dagelijkse patches op MX exchange en ik denk dat dat technisch wel degelijk kan en daarom haal ik het RHEL voorbeeld erbij! Ik denk dat daarom een deel van de verantwoordelijkheid toch ook wel bij MS ligt!
Ik blijf erbij dat organisaties niet verantwoordelijk hoeven te zijn voor de beveiliging van hun IT omgeving, tenzij ze die zelf ook beheren. Doen ze het beheer niet zelf, dan ligt de verantwoordelijkheid bij een partij/ dienstverlener die de IT omgeving voor de organisatie beheerd.
Een organisatie is wel altijd eindverantwoordelijk voor bedrijfsdata. En het is uiteraard ook de verantwoordelijkheid van een organisatie om due diligence toe te passen bij het selecteren van een dienstverlener die hun kroonjuwelen (lees: bedrijfsdata) voor ze gaat verwerken. Maar je kunt moeilijk van de plaatselijke groenteboer, die een mailbox via zijn Internet provider gebruikt, verwachten dat die dat gaat doen. Ook hier weer: water uit de kraan. Maar als de Internet provider in kwestie zijn patchbeleid niet op orde heeft dan kan de groenteboer daar de dupe van worden.
De dienstverlener moet daarom transparant zijn in de diensten die worden aangeboden en de manier waarop ze zijn beveiligd. Helder, duidelijk en liefst zo functioneel mogelijk omschreven zonder te technisch te worden. Onderdeel daarvan is ook patchbeleid en de wijze waarop deze is geimplementeerd. Ik ben het met Hans Rattink eens dat dit meer zichtbaar mag zijn, vaak is het nu niet expliciet beschreven in een overeenkomst. Of zichtbaar zoals een privacy policy. Wellicht dat een landelijk erkend keurmerk daarbij zou kunnen helpen. Maar de transparantie waar ik het over heb moet binnen een grote organisatie die zijn eigen IT spullenboel beheerd van toepassing zijn.
Er is een duidelijk onderscheid tussen policy (beleid) en de implementatie ervan. Laten we policy in dit verband ook niet verwarren met technische policies. Policies die zijn ingesteld op systemen en platformen en die er voor zorgen dat updates/ patches automatisch, op reguliere momenten worden geinstalleerd. Die kunnen wel onderdeel zijn van de implementatie van een beveiligingsbeleid, maar daar gaat het niet over.
Om weer even naar het oorspronkelijke artikel terug te verwijzen, daarin wordt het volgende gezegd:
“It- en securityteams hebben een manier nodig om uniforme policies voor databescherming toe te passen op ieder systeem en platform, zowel on-premises als in de cloud”
Zo’n uniforme policy kan prima worden gebaseerd op het Cybersecurity Framework dat door het National Institute of Standards and Technology (NIST) is gemaakt. Of wat te denken van de ISO 27001 normering, die gaat uiteindelijk over informatie beveiliging.
We hoeven het wiel niet opnieuw uit te vinden volgens mij, dat is al gedaan. Je moet het alleen wel toepassen.
Kijk eens op https://delorentz.nl/ransomware-deel-1 waarin ik praat over bescherming en identificatie met betrekking tot ransomware.
Misschien moet ik mijn punt ietsjes nuanceren: organisaties zijn volgens mij verantwoordelijk voor het correct (laten) beveiligen van data en kunnen daarbij het onderhoud van de onderliggende systemen en diensten eventueel delegeren naar derden. Dat ontslaat ze volgens mij niet van de verantwoording om daarbij dienstverleners te kiezen, die (onder andere) een passend vulnerability management beleid voeren, dat overeenkomt met de vereisten voor de data die door die systemen bewaard en verwerkt wordt. Probleem van dit moment is echter, dat door het ontbreken van transparantie de organisaties die verantwoording inderdaad vaak moeilijk kunnen dragen.
Het goed beleggen van verantwoordelijkheid helpt om organisaties aan te sporen om de juiste maatregelen te (laten) nemen en leveranciers te kiezen, zodat de systemen en data beter tijdig en adequaat beveiligd worden. Hierbij is transparantie over het gevoerde beveiligingsbeleid denk ik de sleutel die dat mogelijk kan maken, waarin het patch beleid goed begrijpelijk in moet zijn verwoord. Met andere woorden, de groenteboer moet eenvoudig een antwoord kunnen krijgen of zijn leverancier beveiligingsmaatregelen snel (genoeg) doorvoert – en een beter voorbeeld is wellicht de lokale boekhouder, die wat meer gevoelige informatie beheert maar nog steeds niet veel weet van IT of Security.
Ik ben het eens met Wilco Turk dat veiligheidsraamwerken zoals NIST en ISO27k en goede standaarden bieden om de gegevensbeveiliging structureel te verbeteren, maar ze vragen ook om inhoudelijke kennis om het resultaat ervan goed te kunnen interpreteren. Dat is voor velen niet weggelegd. Ook kan dit voor veel kleine organisaties een behoorlijke uitdaging zijn om zo’n raamwerk te implementeren.
Daarom zou ik ook niet een nieuwe standaard willen introduceren; wel zou ik voorstander zijn van een soort van “Energielabel voor security”. Daarmee zou niet gereguleerd of gedicteerd hoeven worden, hoe de leveranciers de digitale wereld moeten standaardiseren, maar bieden we wel een houvast voor de meerderheid van de niet IT onderlegde beslissers bij organisaties maar ook bijvoorbeeld de overheid, om een mening te kunnen vormen over het resultaat van de genomen maatregelen. Een NIST of ISO certificering zal dan vrij snel een “groen label” kunnen opleveren maar het biedt ook ruimte om organisaties te kwalificeren zonder die certificeringen, bijvoorbeeld door er kwantitatieve wegingen in op te nemen. Zo kan bijvoorbeeld en onder andere, en zowel voor ISO/NIST gecertificeerde als ongecertificeerde levaranciers meegewogen worden, of kritische patches binnen een dag, week of maand geinstalleerd worden en kan de “groenteboer” een kosten/baten-analyse maken voor zijn digitale leverancier, die wellicht met een B-label “klaar is”, terwijl de locale boekhouder toch echt een “A++” nodig heeft 🙂
Zo komen we nog eens ergens. Ik vindt ‘Energielabel voor security’ een goede bewoording. Zelf zat ik met ‘keurmerk’ in mijn hoofd, maar de analogie met een energielabel is een betere. Een energielabel gaat ook niet in op de achterliggende technische maatregelen die ervoor zorgen dat een apparaat een B, A of A+ label krijgt. Maar beschrijft wel de voorwaarden waar het apparaat aan moet voldoen om zo’n label te verdienen. Dat kun je heel goed vertalen naar voorwaarden waar een organisatie, leverancier of dienstverlener aan moet voldoen om een bepaald IT security label te verdienen.
Een hele grote uitdaging daarbij is dan natuurlijk wel de naleving ervan en de controle erop. Dat vraagt om auditing, een regelmatige ‘keuring’. Bedrijven moeten wel (blijvend) kunnen aantonen dat ze voldoen aan de voorwaarden om een bepaald label te mogen gebruiken.
De NCSC heeft ook al eens een plan geopperd voor de ‘Orde van ict-beveiligers’. Ook daar kun je wat mee, al is het dan meer op de professionals gericht die voor een organisatie, leverancier of dienstverlener werken. Ze beschikken dan bijvoorbeeld over een certificering of opleiding, en er zijn duidelijke regels waaraan ze zich moeten houden. Doen ze dat niet dan worden ze, helaas, uit de ‘orde’ gezet. Een ethische code kortom. En dat kan dan weer bijdragen aan het verkrijgen van het ‘IT security label’, immers men werkt met professionals uit de ‘Orde van ict-beveiligers’.
Het patchen van systemen wordt vaak gezien als saai en lastig. Teams zijn doorgaans al zo overladen met werk dat zelfs het installeren van security patches een lagere prioriteit krijgt, triest maar waar. Daarnaast kan het ook een service onderbreking zijn: bij het installeren van nieuwe software is vaak een restart nodig, niet altijd gewenst.
Een andere reden van uitstel zit ook vaak in afhankelijkheden: het installeren van een nieuwere software versie, patch/upgrade kan effecten hebben bij integraties en koppelingen met andere systemen. De integraties die er tegenwoordig zijn maken het snel patchen en upgraden van systemen er niet eenvoudiger op.
Vanuit architectuur helpt het al wel door services, de essentiële, in een failover structuur te bouwen. Dat geeft dan meer ruimte voor een update/patch zonder service-interruptie, maar dat verkleint de werkdruk niet. Het verder automatiseren van repetitief werk zou daarvoor helpen.
Wederom, patchen zal vlugger beter en vanzelf gaan als de kwaliteit van de updates en de frequentie op orde zijn. Het zou helemaal ultiem zijn als er dan ook vrijwel geen down time is omdat er geen reboot nodig is maar bijv alleen het herstarten van de service zodat nieuwe verbindingen met de gepatchte diensten aan de slag gaan. Alle problemen die hierboven wederom met keurmerken en theorieen en wat allemaal nog meer eigenlijk alleen maar in stand gehouden gaan worden, zullen als sneeuw voor de zon verdwijnen als in de PRAKTIJK het risico loos is elke dag automatisch zonder interrupties patches door te voeren! We hebben met fundamentele kwaliteitsproblemen te maken als je patches en updates doorvoeren instabiele diensten veroorzaken. Gaat niet met een beetje management we gepoetst worden hoor!
Ik snap wat je zegt Martin, en ik zie dat ook in praktijk gebeuren. Maar het mag geen excuus zijn. Net zoals een serviceonderbreking of herstart dat ook niet mag zijn. Soms is een serviceonderbreking of herstart nu eenmaal nodig. Uit ervaring weet ik dat communicatie daarbij erg belangrijk is en dat vrijwel niemand bezwaar heeft tegen een onderbreking als het gaat om de veiligheid van bedrijfsdata.
Eén van de belangrijkste pijlers in cybersecurity is het tijdig updaten en patchen van systemen. Kwetsbaarheden in systemen worden continue misbruikt door kwaadwillenden. En zeker de kwetsbaarheden die net aan het licht zijn gekomen en waar nog geen oplossing voor beschikbaar is. Juist daarom is tijdig updaten en patchen zo belangrijk.
Zoals ik al eerder heb gezegd: je moet beveiliging niet ‘erbij’ doen, maar zien als een fundamenteel onderdeel van IT dienstverlening. Beveiliging als uitgangspunt. Patchen van systemen is wat mij betreft dan ook een reguliere, terugkerende taak. Niet alleen het uitvoeren ervan, ook het controleren erop. Procedureel vastgelegd en onderdeel van de dienstverlening.
Van papieren tijgers naar nietzeggende keurmerken omdat er niemand meer is om de pleisters te plakken doet me denken aan de zorg. Wat er niet is zal er niet vanzelf komen want de cirkelredenering (circulus in probando) van een audit omdat een keurmerk anders een sticker zonder waarde wordt gaat voorbij aan het beginpunt van de discussie. Het negeren van de adviezen – hoe dringend dan ook – gaat om een gemis aan dwang want het is niet NCSC die op de bok zit als bestuurder en daar is een reden voor.