Security-no-brainers: een kip-ei verhaal?

20 mei Security-no-brainers: een kip-ei verhaal?

In het vaktijdschrift Informatiebeveiliging (2016 #3) betoogt een cybersecurity consultant dat het afvinken van kwetsbaarhedenlijsten de onderliggende ontwikkel- en beheerprocessen niet verbetert. Hierdoor zal het beveiligingsniveau door de tijd heen eroderen en zullen nieuwe servers dezelfde kwetsbaarheden bevatten.

Deze observatie is wat mij betreft slechts ten dele waar: het alleen maar oplossen van kwetsbaarheden is inderdaad niet voldoende. Tegelijkertijd ken ik genoeg organisaties die vulnerability scanning gebruiken om beter te beheren en secure software development te bereiken. Vulnerability scanners bieden namelijk resultaten die je als key-performance indicators kunt inzetten. Met andere woorden, met goede scanning en rapportages kun je juist aantonen hoe goed je beheert/ontwikkelt en of je verbetering laat zien. In het artikel wordt ook ingegaan op no-brainer-security-metrics, ook daar is wat mij betreft een kanttekening bij te plaatsen.

No-brainer-security-metrics

In zijn artikel introduceert de consultant een aantal no-brainer-security-metrics. Als je beveiliging goed implementeert, zo is zijn stelling, dan eindig je niet met beveiligingsblunders in je systeem. Enkele voorbeelden:

• Als je patch-management goed uitvoert, draait de server geen Apache-versie die end-of-life is.
• Als je SSH juist configureert, zal het geen cryptografische sleutel hebben die zo kort is dat deze eenvoudig kan worden gekraakt.
• Als je de server goed beheert, zal deze niet voorkomen op een blacklist voor malware distributie.
• Als een gebruiker zich bewust is van informatiebeveiliging, zal ze haar wachtwoord niet aan een ander geven.

Hij concludeert vervolgens dat een security-no-brainer het ergste is dat je kunt vinden tijdens een securitycheck. Deze no-brainers zijn in zijn optiek namelijk met goed beheer te voorkomen. Wat mij betreft slaat de cybersecurity consultant hier de plank flink mis. Hij gaat er in bovenstaande voorbeelden namelijk vanuit dat patchmanagement altijd goed wordt uitgevoerd, dat SSH altijd juist wordt geconfigureerd, dat servers altijd goed worden beheerd en dat een gebruiker nooit een wachtwoord afgeeft.

Ik ga er vanuit dat de consultant met goed patchmanagement een duidelijk proces bedoelt waardoor patches/updates binnen een vooraf vastgestelde tijd, nadat ze zijn uitgebracht, worden getest en geïnstalleerd. Een patch wordt uitgebracht omdat er een kwetsbaarheid in het systeem aanwezig is. De enige manier om hier tijdig achter te komen is om doorlopend op kwetsbaarheden te scannen. Vervolgens kost het downloaden, testen en installeren van de patch tijd. Soms is dat slecht patchmanagement, maar vaker heeft het praktische oorzaken: beheerders hebben meer werkzaamheden, niet alle machines zijn tegelijkertijd online en veel machines kunnen alleen tijdens vooraf vastgestelde maintenance windows herstart worden. In veel gevallen wordt er dus aan goed patchmanagement gedaan, maar blijven er toch (tijdelijk) kwetsbaarheden in het systeem aanwezig. Vulnerability scanners kunnen juist helpen door kwetsbaarheden tijdig in kaart te brengen, zodat beheerders alternatieve maatregelen kunnen treffen.

Het gezegde ‘waar gehakt wordt vallen spaanders’ geldt ook binnen de informatiebeveiliging. Als beheerder/ontwikkelaar kun je je blindstaren op de procedures en daarmee een onwerkbaar computersysteem of programma creëren. Sterker nog: een rigide implementatie kan zorgen voor nieuwe beveiligingsproblemen. Een te lang SSH wachtwoord wordt dan bijvoorbeeld opgeslagen in een Word-document op Dropbox, met alle gevolgen van dien.

Naar mijn mening hebben we bij security-no-brainers te maken met een kip-ei verhaal: goede processen kunnen blunders voorkomen, maar niet ieder proces gaat altijd goed. Om die reden moet je controleren, bijvoorbeeld door vulnerability scanning toe te passen. De resultaten van die scans kunnen weer gebruikt worden voor het aanscherpen van de processen. Op deze manier heb je een doorlopend kwaliteitsborging en – verbeteringsproces.