XS4ALL CSO: Leger moet internet niet beschermen
Volgens XS4ALL Chief Security Officer (CSO) Scott McIntyre moet het leger zich niet met de veiligheid van het internet bemoeien. McIntyre werd door een comité van de Britse Lords ondervraagd over de kwetsbaarheid van het web voor cyberaanvallen, technisch falen en natuurrampen. De CSO merkt op dat grootschalige problemen zelden voorkomen, en in veel gevallen via "best practices" zijn te voorkomen. De internet-industrie doet volgens McIntyre voldoende om de stabiliteit van het internet te beschermen. Meer toezicht is dan ook niet nodig en zou zelfs meer kwaad dan goed doen.
Paniek
Regelmatig wijzen beleidsmakers naar de DDoS-aanvallen op Estland (2007) en Georgië (2008). Iets waar ook de Britten zich zorgen over maken, maar volgens de CSO is dat onterecht. De betrokken internetproviders waren namelijk niet met standaard internet security practices bekend, waardoor de schade veel groter was dan die had hoeven zijn.
Door de gebeurtenissen in Estland is de NAVO zich ook meer met cyberspace gaan bemoeien. Op de vraag of het leger betrokken moet worden in de bescherming van het internet is McIntyre duidelijk. "Absoluut niet." Toch adviseert het comité meer samenwerking tussen de Europese Unie en NAVO, waarbij het ook oefeningen met de Verenigde Staten aanraadt.
Wat betreft botnets moet het comité hier volgens McIntyre bewust van zijn, maar zich niet al teveel zorgen over maken. "Geen paniek", zo laat hij weten. "Overheden en de EU moeten ervoor zorgen dat de mensen in Operationele Security de ondersteuning krijgen die ze nodig hebben om hun werk te doen."
CERTS
Op de vraag of door de overheid bestuurde Computer Emergency Response Teams (CERTs) geschikt zijn voor het bestrijden van internet incidenten, is de Chief Security Officer wederom duidelijk. Die zijn daar volgens hem absoluut niet geschikt voor. CERTs zoals GOVCERT moeten zich alleen richten op de IT-infrastructuur van bepaalde overheidsinstanties. De meeste overheden hebben niet eens hun eigen IT-huishouding op orde en nationale CERTS zijn slechts één speler in een grote wereld van respons teams.
Daarom ziet hij ook geen rol voor het Europees agentschap voor netwerk- en informatiebeveiliging (ENISA). "Het toevoegen van meer lagen voor incident respons werk in de vorm van een nationale CERT vertraagt het proces alleen maar, voegt bureaucratie toe, vertroebelt incident details en leidt tot vinger wijzen."
Echter vraag ik mij dan wel af wie het moet gaan regelen, niet elke provider is competent genoeg om dit te melden/af-te-slaan. And When the shit hits te fan er geen duidelijkheden zijn.
Er moet wel ergens een centrale organisatie zijn die het aanstuurt en bepaalde policy's maakt, maar niet die het beheerd!
Regelgeving? Van wie? Je kunt nog zo goed regels bedenken, maar als een land beslist dat die regels daar niet geimplementeerd worden, of dat ze die niet geldig verklaren voor hun eigen onderdanen, dan heb je er niets aan. In de praktijk is gebleken dat alles veel soepeler gaat als de CERT's van de verschillende providers onderling zaken afstemmen.
Een telefoontje naar de CERT van een provider in een willekeurig ander land gaat vele malen sneller dan een en ander regelen via een soort "internationaal verzoek om rechtshulp".
Peter
Regelgeving? Van wie? Je kunt nog zo goed regels bedenken, maar als een land beslist dat die regels daar niet geimplementeerd worden, of dat ze die niet geldig verklaren voor hun eigen onderdanen, dan heb je er niets aan. In de praktijk is gebleken dat alles veel soepeler gaat als de CERT's van de verschillende providers onderling zaken afstemmen.
Een telefoontje naar de CERT van een provider in een willekeurig ander land gaat vele malen sneller dan een en ander regelen via een soort "internationaal verzoek om rechtshulp".
Peter
Regelgeving, vanuit de overheid waaronder een zeker provider valt. Ik doel hiermee op het volgende:
"....Regelmatig wijzen beleidsmakers naar de DDoS-aanvallen op Estland (2007) en Georgië (2008). Iets waar ook de Britten zich zorgen over maken, maar volgens de CSO is dat onterecht. De betrokken internetproviders waren namelijk niet met standaard internet security practices bekend, waardoor de schade veel groter was dan die had hoeven zijn. ...."
Ik vind dat je een basiskwaliteit van een provider mag verwachten voor internet diensten. Daaronder valt ook een zekere mate van aanpak van security risico's. Een provider alleen heeft niet alles onder controle maar kan wel de nodige maatregelen nemen en ik denk dat daar best regelgeving voor mag zijn. Net zoals dat geldt voor auto's en heel veel andere producten.
Zoals al eerder gesteld, ligt het probleem in het feit dat ieder land andere eisen stelt aan de basiskwaliteit van de providers. In Frankrijk, en binnenkort UK, wordt de belangrijkste eis dat men snel downloaders kan afsluiten. De hele wetgeving t.a.v. van providers in die landen richt zich daarop en niet op het voorkomen van DDoS. Politici kijken naar de commerciele belangen van de lokale lobby-groepen. En tot nu toe maakt het de landen niet uit of er een DDoS uit hun land komt. Zolang hun eigen netwerk maar niet aangepakt wordt. En ik ben bang dat dit nog heel lang zal duren.
Voor zover ik weet is Nederland een van de weinige landen waarbij er structureel overleg is tussen providers om DDoS aanvallen aan te pakken.
Peter
Elk beursgenoteerd bedrijf moet voldoen aan een sas70 type 2
certificering, anders worden ze van de beurs gehaald.
maarja..... voordat dat doordringt zijn we weer 10 jaar verder.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
