Belgische overheid wil bugmelding alleen via beveiligd zip-bestand ontvangen
Wie een kwetsbaarheid bij de Belgische overheid wil rapporteren zal dit via een met een wachtwoord beveiligd zip-bestand moeten doen, omdat de melding anders door de spamfilters kan worden onderschept. Zo laat het Centrum voor Cybersecurity België (CCB) van de Belgische overheid weten.
Onlangs kreeg België een nieuw wettelijk kader voor het melden van kwetsbaarheden. Dit kader beschrijft hoe een beveiligingsonderzoeker zonder frauduleuze bedoelingen of de intentie om schade te berokkenen, bestaande kwetsbaarheden in netwerken en informatiesystemen in België kan opsporen en moet melden. De onderzoeker mag alleen handelingen uitvoeren die noodzakelijk zijn om het bestaan van de kwetsbaarheid aan te tonen.
Tenzij er vooraf een beloning afgesproken is, zoals bijvoorbeeld bij een bugbountyprogramma of een afgesproken penetratietest, mag de onderzoeker geen beloning of betaling eisen. Een van de nieuwe bepalingen is dat een ontdekte kwetsbaarheid zo snel mogelijk moet worden gemeld aan de verantwoordelijke eigenaar van het systeem en daarna bij het CCB. Tenslotte mag de kwetsbaarheid alleen na toestemming van het CCB openbaar worden gemaakt.
Via de eigen website biedt het CCB een meldingsformulier voor de bugmeldingen. Dat moet worden ingevuld en gemaild aan de overheidsinstantie. Daarvoor gelden wel verschillende eisen. "Het ingevulde formulier moet ons worden bezorgd in Word- of pdf-formaat en met een paswoord of zip-bestand beveiligd zijn (om een eventuele blokkering door onze antivirusfilters te vermijden)", aldus een uitleg van de procedure. Daarnaast mag het zip-bestand niet groter dan zeven megabyte zijn.
Simple oplossing: gewoon niet melden en stik er maar in.
Ze hadden ook uploads kunnen gebruiken op een webserver, maar daar zitten ook nadelen aan. En het mag bijvoorbeeld niet van de beveiligingsregels van de overheid wegens het hoge risico.
De wet beschermt juist de melder! Juist als deze aan voorwaarden voldoet, zoals geen misbruik te hebben gemaakt van de gevonden kwetsbaarheid en melden aan organisatie en CCB. Voor de rest is het common sense om een organisatie de tijd te geven om de kwetsbaarheid te verhelpen.
Het CCB wil graag van België het meest cyberveilige land van Europa maken en zijn daarmee in middelen voor burgers en organisaties verder dan Nederland. En ook qua wetgeving. En toegegeven het is nodig!
(je bent afhankelijk van de waan van de dat wat spamfiltering betreft bij je outsourcing partner, en je bent daar natuurlijk niet de enige klant)
Het is jaren zo geweest dat als je een oplichting mail doorstuurde aan "valse-email@abnamro.nl" (het door hen zelf aangegeven adres daarvoor en "de algemene standaard"), dit regelrecht gebounced werd met een melding van het spamfilter van hun e-mail provider messagelabs.
Zelf heb ik dit soort ellende ook wel gehad met mail die bij Office365 gehost is. Er zijn allerlei criteria waarmee mail rejected wordt zelfs al VOOR hij toekomt aan ingestelde whitelists enzo. En die veranderen per maand, al dan niet aangekondigd.
Gaan we nu werkelijk verlangen dat alles gemakkelijk en snel moet terwijl we met security bezig zijn?
En non-disclosure is ook wat in Nederland ook ongeveer overal in Responsible Disclosure policies staat.
Is dat werkelijk zo onredelijk dan?
Als men wil klagen, moet men klagen over de tijd die het duurde voordat dit er kwam.
Als tijdens de exodus door de woestijn.
Veel filters blokkeren juist beveiligde zip-bestanden omdat ze die niet kunnen conroleren.
Peter
Maar dat zal hier duidelijk niet het geval zijn bij de ontvanger, anders adviseerden ze het niet. Bij de verzender kan het nog steeds mis gaan, maar dat ziet de verzender direct.
Ik heb zelf ook wel eens de ervaring gehad dan spamfilters mail met stukken computercode blokkeerden. Het sturen als zip of pdf hielp niet. Aan encryptie heb ik toen niet gedacht. In een specifieke geval waren het zowel de spamfilters van Ziggo (bij het verzenden) en van KPN (bij het ontvangen) die mijn onschuldige code tegenhielden.
Na lang gepuzzel bleek een totaal onschuldige url in de code de trigger te zijn.
Ik denk dat het een goed advies is. In dit geval kun je het wachtwoord gewoon in dezelfde mail zetten.
Maar dat zal hier duidelijk niet het geval zijn bij de ontvanger, anders adviseerden ze het niet. Bij de verzender kan het nog steeds mis gaan, maar dat ziet de verzender direct.
Ik heb zelf ook wel eens de ervaring gehad dan spamfilters mail met stukken computercode blokkeerden. Het sturen als zip of pdf hielp niet. Aan encryptie heb ik toen niet gedacht. In een specifieke geval waren het zowel de spamfilters van Ziggo (bij het verzenden) en van KPN (bij het ontvangen) die mijn onschuldige code tegenhielden.
Na lang gepuzzel bleek een totaal onschuldige url in de code de trigger te zijn.
Ik denk dat het een goed advies is. In dit geval kun je het wachtwoord gewoon in dezelfde mail zetten.
Inderdaad.
Het is een praktisch probleem in heel veel organisaties, dat zo'n security meld-adres een heel speciaal geval is voor de "standaard" IT omgeving.
(net als wat meer "interne IT" die om veel redenen ook wel moeten vechten met de standaard KA werkplek - denk vendor management tools, legacy als Java/Flash browsers )
En wat veel van de scholieren met security interesse hier zich niet realiseren is dat een security team geen almachtige beslissers zijn die de hele IT boel kunnen laten ombouwen naar hun specifieke behoefte .
En evenmin mogen hobby-Bob-pen met een stukje shadow-IT waar ze hun speciale dingetje doen .
(gewoon, subdomeintje, zelf VPSje runnen, en daar de mail op ontvangen ).
Dus ja - het ziet er knullig uit , maar dat is gewoon gevolg van de realiteit om grootschalige (IT)organisaties waar heel rare uitzonderingen moeilijker/duurder/onmogelijker zijn dan een advies voor een workaround.
Klopt en daarnaast is het een knullige ouderwetse oplossing met een scala aan bijbehorende problemen.
Als valt of staat nogsteeds bij de sterkte van het wachtwoord wat tevens uitgewisseld moet worden, dat zorgt op z'n plaats weer veer andere problemen.
Wat een 1999 oplossing.
Klopt
Clamav en f-prot bijvoorbeeld konden zelfs gezip'te zip bestanden tot x level diep scannen.
Later werd dat overbodig met de komst van Wetransfer en andere cloud-oplossingen.
De oplossing met een formulier met evt password en versturen van encrypted file is een veilige oplossing. Files kunnen ook niet door applicaties automatisch gelezen worden / testscript uitgevoerd. Voor (ethical) hackers is het invullen van een formulier echt niet veel echtra werk, naast het goed documenteren van de vulnerability.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Specialiseer je in Forensisch ICT
Online informatieavond 19 november
Wil jij je specialiseren in digitaal forensisch onderzoek? Je kennis verbreden en tech-nische vaardigheden ontwikkelen? Ontdek de cursus- en opleidingsmogelijkheden van Hogeschool Leiden:
- Bachelor Informatica Forensisch ICT (deeltijd)
- Master Digital Forensics (vol- en deeltijd)
- Module Mobile Forensics
- Module Data Analytics
Interesse? Meld je aan!
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.
