NCSC-NL discrimineert in disclosure-proces
Beste allemaal, Aanstaande maandag word blijkbaar "RPKI-patchdag"! Er zitten problemen in meerdere RPKI-validators. En zoals jullie misschien weten, beheer ik zelf een aantal veel gebruikte RPKI software packages. Maar anders dan "we vermoeden dat er een probleem in jouw RPKI-software zit" heeft NCSC-NL geen informatie aan mij verstrekt waar ik op kan handelen. Ik wil een aantal kanttekeningen plaatsen bij het beleid van NCSC-NL. Het komt op mij over alsof NCSC-NL een discriminerend beleid voert aangaande welke mensen wanneer worden betrokken in zogenaamde "coordinated vulnerability disclosure" (CVD) processen. Een van de ideeën achter "CVD" is dat het voor de verschillende betrokken software- ontwikkelaars een 'level playing field' creëert: niemand krijgt extra voordeel. Maar... die vlieger gaat natuurlijk niet op wanneer men mij eergisterenavond informeert dat er aanstaande maandag mogelijk 0-days aankomen, terwijl andere softwareontwikkelaars al MEERDERE WEKEN geleden op de hoogte gebracht waren! Het NCSC wilde enkel concrete informatie verstrekken als ik akkoord zou gaan met een full disclosure-publicatie aanstaande maandag. Maar de boel loopt vast als het NCSC niet vertelt wat het probleem is, waardoor ik niet kan beoordelen hoeveel tijd nodig is, en dus geen idee heb of we voor maandag überhaupt een oplossing hebben voor onze gebruikers. Ik ga niet akkoord met zulke knetterstrakke deadlines. Ik kan geen blinde cheque schrijven. Want stel: wat als het gerapporteerde probleem een maand kost om op te lossen? Of wat als: het probleem blijkt een topje van een ijsberg te zijn, en de scope bij meerdere validators groter is? (Ik plaats vraagtekens bij NCSC-NL's vermogen om BGP/RPKI problemen te beoordelen!) Waarom ging NCSC-NL geen gesprek aan met mij? Naar eigen zeggen vinden ze problematisch dat het OpenBSD project in de zogenoemde 'full disclosure' methode gelooft (zie: https://www.openbsd.org/security.html). Echter, het feit dat OpenBSD duidelijk omschrijft wat het project belangrijk vindt, zegt natuurlijk niet dat we idioten zijn die geen geheim kunnen bewaren. (hallo, wij beheren iedereen's openssh, en ook libcrypto op je Mac, en natuurlijk schitterende IKE/IPsec/RPKI/SMTP/BGP implementaties...) Ik kan prima over NDAs onderhandelen en afspraken maken met mensen die een ons probleem aanmelden. Maar dan moet men wel een gesprek aanknopen. Het is mogelijk voor 'andersgelovigen' om productief met elkaar samen te werken. Voor zover ik kan beoordelen heeft NCSC-NL enkel overlegd met een handjevol programmeurs. Verder lijkt het er op dat er geen enkele default-free network operator op de hoogte is gesteld. In mijn optiek is bij RPKI/BGP securityproblemen een heel belangrijk aspect de deployment te coordineren tussen globale ISP / IXPs. Er is niet nagedacht over hoe ISPs nieuwe software versies moeten kwalificeren alvorens ze uitgerold kunnen worden, en hoeveel tijd dit kost. Dit is kostbare tijd waarin allerlei ISPs vanaf maandag dus mogelijk kwetsbaar zijn. Ook bestaan er verschillende operationele 'trust circles' specifiek voor het onderwerp Internet routing. NCSC-NL heeft hier blijkbaar geen weet van, en dus geen gebruik van kunnen te maken. Gemiste kans! In deze casus lijkt het NCSC-NL onzorgvuldig gehandeld te hebben met mogelijk sensitieve informatie over kritieke Internet infrastructuur. Wat mij betreft niet voor herhaling vatbaar. Met vriendelijke groeten, Job
----- On Oct 28, 2021, at 1:52 PM, Job Snijders job@instituut.net wrote: Hey Job,
In deze casus lijkt het NCSC-NL onzorgvuldig gehandeld te hebben met
Het NCSC-NL is een overheidsorganisatie. Je kan dus, naast een zaak aanspannen bij de bestuursrechter, op basis van de Wet Openbaarheid Bestuur proberen te er achter te komen wat hun beweegredenen zijn. Als er schade ontstaat door het handelen van de overheid, kunnen de gedupeerden deze natuurlijk proberen te verhalen bij de rechter. Groetjes, Sabri
* job@instituut.net (Job Snijders) [Thu 28 Oct 2021, 22:52 CEST]:
Aanstaande maandag word blijkbaar "RPKI-patchdag"! Er zitten problemen in meerdere RPKI-validators. En zoals jullie misschien weten, beheer ik zelf een aantal veel gebruikte RPKI software packages.
Randy Bush is zo te zien ook niet blij met het disclosure-proces: https://mailman.nanog.org/pipermail/nanog/2021-October/216309.html |received this vuln notice four days before these children intend to |disclose. so you can guess how inclined to embargo. | |randy -- Niels.
Hey Job, Wat mij betreft vervult het NCSC al een hele tijd (zo niet vanaf het begin) een op zijn minst discutabele maar waarschijnlijk schadelijke rol als het om “cyber security” gaat. Te bezopen voor woorden, maar jouw verhaal verbaast me dus totaal niet. In mijn tijd bij NBIP (ik ben daar recent gestopt) liepen we daar ook tegenaan. Mijn zegen en steun heb je om ze publiekelijk aan de schandpaal te nagelen. Afgezien van het feit dat ze dat gewoon verdienen gebeurt er dan misschien (eindelijk) eens wat. -- Groeten, Alex Bik
Op 28 okt. 2021 om 22:52 heeft Job Snijders <job@instituut.net> het volgende geschreven:
Beste allemaal,
Aanstaande maandag word blijkbaar "RPKI-patchdag"! Er zitten problemen in meerdere RPKI-validators. En zoals jullie misschien weten, beheer ik zelf een aantal veel gebruikte RPKI software packages.
Maar anders dan "we vermoeden dat er een probleem in jouw RPKI-software zit" heeft NCSC-NL geen informatie aan mij verstrekt waar ik op kan handelen.
Ik wil een aantal kanttekeningen plaatsen bij het beleid van NCSC-NL. Het komt op mij over alsof NCSC-NL een discriminerend beleid voert aangaande welke mensen wanneer worden betrokken in zogenaamde "coordinated vulnerability disclosure" (CVD) processen.
Een van de ideeën achter "CVD" is dat het voor de verschillende betrokken software- ontwikkelaars een 'level playing field' creëert: niemand krijgt extra voordeel.
Maar... die vlieger gaat natuurlijk niet op wanneer men mij eergisterenavond informeert dat er aanstaande maandag mogelijk 0-days aankomen, terwijl andere softwareontwikkelaars al MEERDERE WEKEN geleden op de hoogte gebracht waren!
Het NCSC wilde enkel concrete informatie verstrekken als ik akkoord zou gaan met een full disclosure-publicatie aanstaande maandag. Maar de boel loopt vast als het NCSC niet vertelt wat het probleem is, waardoor ik niet kan beoordelen hoeveel tijd nodig is, en dus geen idee heb of we voor maandag überhaupt een oplossing hebben voor onze gebruikers.
Ik ga niet akkoord met zulke knetterstrakke deadlines. Ik kan geen blinde cheque schrijven. Want stel: wat als het gerapporteerde probleem een maand kost om op te lossen?
Of wat als: het probleem blijkt een topje van een ijsberg te zijn, en de scope bij meerdere validators groter is? (Ik plaats vraagtekens bij NCSC-NL's vermogen om BGP/RPKI problemen te beoordelen!)
Waarom ging NCSC-NL geen gesprek aan met mij? Naar eigen zeggen vinden ze problematisch dat het OpenBSD project in de zogenoemde 'full disclosure' methode gelooft (zie: https://www.openbsd.org/security.html).
Echter, het feit dat OpenBSD duidelijk omschrijft wat het project belangrijk vindt, zegt natuurlijk niet dat we idioten zijn die geen geheim kunnen bewaren. (hallo, wij beheren iedereen's openssh, en ook libcrypto op je Mac, en natuurlijk schitterende IKE/IPsec/RPKI/SMTP/BGP implementaties...)
Ik kan prima over NDAs onderhandelen en afspraken maken met mensen die een ons probleem aanmelden. Maar dan moet men wel een gesprek aanknopen. Het is mogelijk voor 'andersgelovigen' om productief met elkaar samen te werken.
Voor zover ik kan beoordelen heeft NCSC-NL enkel overlegd met een handjevol programmeurs. Verder lijkt het er op dat er geen enkele default-free network operator op de hoogte is gesteld.
In mijn optiek is bij RPKI/BGP securityproblemen een heel belangrijk aspect de deployment te coordineren tussen globale ISP / IXPs.
Er is niet nagedacht over hoe ISPs nieuwe software versies moeten kwalificeren alvorens ze uitgerold kunnen worden, en hoeveel tijd dit kost. Dit is kostbare tijd waarin allerlei ISPs vanaf maandag dus mogelijk kwetsbaar zijn.
Ook bestaan er verschillende operationele 'trust circles' specifiek voor het onderwerp Internet routing. NCSC-NL heeft hier blijkbaar geen weet van, en dus geen gebruik van kunnen te maken. Gemiste kans!
In deze casus lijkt het NCSC-NL onzorgvuldig gehandeld te hebben met mogelijk sensitieve informatie over kritieke Internet infrastructuur. Wat mij betreft niet voor herhaling vatbaar.
Met vriendelijke groeten,
Job _______________________________________________ NLNOG mailing list NLNOG@nlnog.net http://mailman.nlnog.net/listinfo/nlnog
NCSC heeft een statement hierover gepubliceerd: https://www.ncsc.nl/actueel/nieuws/2021/oktober/29/aanstaande-bekendmaking-c... Groetjes, Teun
On 29 Oct 2021, at 09:42, Alex Bik via NLNOG <nlnog@nlnog.net> wrote:
Hey Job,
Wat mij betreft vervult het NCSC al een hele tijd (zo niet vanaf het begin) een op zijn minst discutabele maar waarschijnlijk schadelijke rol als het om “cyber security” gaat. Te bezopen voor woorden, maar jouw verhaal verbaast me dus totaal niet. In mijn tijd bij NBIP (ik ben daar recent gestopt) liepen we daar ook tegenaan.
Mijn zegen en steun heb je om ze publiekelijk aan de schandpaal te nagelen. Afgezien van het feit dat ze dat gewoon verdienen gebeurt er dan misschien (eindelijk) eens wat.
-- Groeten, Alex Bik
Op 28 okt. 2021 om 22:52 heeft Job Snijders <job@instituut.net> het volgende geschreven:
Beste allemaal,
Aanstaande maandag word blijkbaar "RPKI-patchdag"! Er zitten problemen in meerdere RPKI-validators. En zoals jullie misschien weten, beheer ik zelf een aantal veel gebruikte RPKI software packages.
Maar anders dan "we vermoeden dat er een probleem in jouw RPKI-software zit" heeft NCSC-NL geen informatie aan mij verstrekt waar ik op kan handelen.
Ik wil een aantal kanttekeningen plaatsen bij het beleid van NCSC-NL. Het komt op mij over alsof NCSC-NL een discriminerend beleid voert aangaande welke mensen wanneer worden betrokken in zogenaamde "coordinated vulnerability disclosure" (CVD) processen.
Een van de ideeën achter "CVD" is dat het voor de verschillende betrokken software- ontwikkelaars een 'level playing field' creëert: niemand krijgt extra voordeel.
Maar... die vlieger gaat natuurlijk niet op wanneer men mij eergisterenavond informeert dat er aanstaande maandag mogelijk 0-days aankomen, terwijl andere softwareontwikkelaars al MEERDERE WEKEN geleden op de hoogte gebracht waren!
Het NCSC wilde enkel concrete informatie verstrekken als ik akkoord zou gaan met een full disclosure-publicatie aanstaande maandag. Maar de boel loopt vast als het NCSC niet vertelt wat het probleem is, waardoor ik niet kan beoordelen hoeveel tijd nodig is, en dus geen idee heb of we voor maandag überhaupt een oplossing hebben voor onze gebruikers.
Ik ga niet akkoord met zulke knetterstrakke deadlines. Ik kan geen blinde cheque schrijven. Want stel: wat als het gerapporteerde probleem een maand kost om op te lossen?
Of wat als: het probleem blijkt een topje van een ijsberg te zijn, en de scope bij meerdere validators groter is? (Ik plaats vraagtekens bij NCSC-NL's vermogen om BGP/RPKI problemen te beoordelen!)
Waarom ging NCSC-NL geen gesprek aan met mij? Naar eigen zeggen vinden ze problematisch dat het OpenBSD project in de zogenoemde 'full disclosure' methode gelooft (zie: https://www.openbsd.org/security.html).
Echter, het feit dat OpenBSD duidelijk omschrijft wat het project belangrijk vindt, zegt natuurlijk niet dat we idioten zijn die geen geheim kunnen bewaren. (hallo, wij beheren iedereen's openssh, en ook libcrypto op je Mac, en natuurlijk schitterende IKE/IPsec/RPKI/SMTP/BGP implementaties...)
Ik kan prima over NDAs onderhandelen en afspraken maken met mensen die een ons probleem aanmelden. Maar dan moet men wel een gesprek aanknopen. Het is mogelijk voor 'andersgelovigen' om productief met elkaar samen te werken.
Voor zover ik kan beoordelen heeft NCSC-NL enkel overlegd met een handjevol programmeurs. Verder lijkt het er op dat er geen enkele default-free network operator op de hoogte is gesteld.
In mijn optiek is bij RPKI/BGP securityproblemen een heel belangrijk aspect de deployment te coordineren tussen globale ISP / IXPs.
Er is niet nagedacht over hoe ISPs nieuwe software versies moeten kwalificeren alvorens ze uitgerold kunnen worden, en hoeveel tijd dit kost. Dit is kostbare tijd waarin allerlei ISPs vanaf maandag dus mogelijk kwetsbaar zijn.
Ook bestaan er verschillende operationele 'trust circles' specifiek voor het onderwerp Internet routing. NCSC-NL heeft hier blijkbaar geen weet van, en dus geen gebruik van kunnen te maken. Gemiste kans!
In deze casus lijkt het NCSC-NL onzorgvuldig gehandeld te hebben met mogelijk sensitieve informatie over kritieke Internet infrastructuur. Wat mij betreft niet voor herhaling vatbaar.
Met vriendelijke groeten,
Job _______________________________________________ NLNOG mailing list NLNOG@nlnog.net http://mailman.nlnog.net/listinfo/nlnog
NLNOG mailing list NLNOG@nlnog.net http://mailman.nlnog.net/listinfo/nlnog
On Sat, Oct 30, 2021 at 09:19:32AM +0200, Teun Vink wrote:
NCSC heeft een statement hierover gepubliceerd: https://www.ncsc.nl/actueel/nieuws/2021/oktober/29/aanstaande-bekendmaking-c...
Het NCSC zegt: "De ontwikkelaars van RPKI-client hebben het NCSC laten weten dat zij niet akkoord gaan met betrokkenheid onder embargo." Ik ben niet akkoord gegaan omdat de voorwaarden van het embargo niet acceptabel waren: de tijdlijn is in mijn optiek te krap. Ook werd geen ruimte geboden een analyse te maken van wat dan wel een goede tijdlijn zou kunnen zijn (met wederzijdse goedkeuring). Met vriendelijke groeten, Job ps. Wel fijn dat NCSC nu iedereen formeel een heads-up heeft gegeven aanstaande maandag vrij te houden in de agenda!
Beste allemaal, Nieuws! In goed overleg is er besloten de tijdlijnen aan te passen om meerdere belanghebbenden de mogelijkheid te geven analyses te maken. Ik wil mijn dank uitspreken naar alle mensen die on-list, off-list, en via appjes de wens uitspraken voor koerswijzigingen binnen deze casus. Weinig is mooier dan samen met de lijnen volledig open het Internet veiliger te maken! Met vriendelijke groeten, Job
Hi, Toegegeven dat mijn mening wellicht beïnvloed is door mijn negatieve oordeel over het NCSC als gevolg van acties cq inacties uit het verleden, vind ik het een slap verhaal. Er zit een wereld tussen niet geheimzinnig doen over bugs en ontwikkelaars de tijd geven problemen op te lossen alvorens ze wereldkundig te maken. Het is absoluut niet zo zwart-wit als het NCSC de wereld wil doen geloven. Het is niet of-of. Je kunt best ontwikkelaars op de hoogte stellen en vooraf afspreken dat en wanneer de boel wereldkundig gemaakt wordt. Bovendien verschuilen ze zich - zoals gebruikelijk - weer achter de wet. Een wet waar we ons overigens allemaal aan moeten houden, daar is het NCSC niet uniek in. Wat mij betreft sluit dit naadloos aan bij eerdere acties / inacties van het NCSC waarbij ze informatie die ze hadden weigerden te delen met de mensen die er daadwerkelijk wat aan konden doen. Dit komt op mij meer over als “straatje schoonvegen” dan als het daadwerkelijk veiliger proberen te maken van het (Nederlandse deel van het) internet. -- Groeten, Alex Bik
Op 30 okt. 2021 om 09:19 heeft Teun Vink <teun@teun.tv> het volgende geschreven:
NCSC heeft een statement hierover gepubliceerd: https://www.ncsc.nl/actueel/nieuws/2021/oktober/29/aanstaande-bekendmaking-c...
Groetjes, Teun
On 29 Oct 2021, at 09:42, Alex Bik via NLNOG <nlnog@nlnog.net> wrote:
Hey Job,
Wat mij betreft vervult het NCSC al een hele tijd (zo niet vanaf het begin) een op zijn minst discutabele maar waarschijnlijk schadelijke rol als het om “cyber security” gaat. Te bezopen voor woorden, maar jouw verhaal verbaast me dus totaal niet. In mijn tijd bij NBIP (ik ben daar recent gestopt) liepen we daar ook tegenaan.
Mijn zegen en steun heb je om ze publiekelijk aan de schandpaal te nagelen. Afgezien van het feit dat ze dat gewoon verdienen gebeurt er dan misschien (eindelijk) eens wat.
-- Groeten, Alex Bik
Op 28 okt. 2021 om 22:52 heeft Job Snijders <job@instituut.net> het volgende geschreven:
Beste allemaal,
Aanstaande maandag word blijkbaar "RPKI-patchdag"! Er zitten problemen in meerdere RPKI-validators. En zoals jullie misschien weten, beheer ik zelf een aantal veel gebruikte RPKI software packages.
Maar anders dan "we vermoeden dat er een probleem in jouw RPKI-software zit" heeft NCSC-NL geen informatie aan mij verstrekt waar ik op kan handelen.
Ik wil een aantal kanttekeningen plaatsen bij het beleid van NCSC-NL. Het komt op mij over alsof NCSC-NL een discriminerend beleid voert aangaande welke mensen wanneer worden betrokken in zogenaamde "coordinated vulnerability disclosure" (CVD) processen.
Een van de ideeën achter "CVD" is dat het voor de verschillende betrokken software- ontwikkelaars een 'level playing field' creëert: niemand krijgt extra voordeel.
Maar... die vlieger gaat natuurlijk niet op wanneer men mij eergisterenavond informeert dat er aanstaande maandag mogelijk 0-days aankomen, terwijl andere softwareontwikkelaars al MEERDERE WEKEN geleden op de hoogte gebracht waren!
Het NCSC wilde enkel concrete informatie verstrekken als ik akkoord zou gaan met een full disclosure-publicatie aanstaande maandag. Maar de boel loopt vast als het NCSC niet vertelt wat het probleem is, waardoor ik niet kan beoordelen hoeveel tijd nodig is, en dus geen idee heb of we voor maandag überhaupt een oplossing hebben voor onze gebruikers.
Ik ga niet akkoord met zulke knetterstrakke deadlines. Ik kan geen blinde cheque schrijven. Want stel: wat als het gerapporteerde probleem een maand kost om op te lossen?
Of wat als: het probleem blijkt een topje van een ijsberg te zijn, en de scope bij meerdere validators groter is? (Ik plaats vraagtekens bij NCSC-NL's vermogen om BGP/RPKI problemen te beoordelen!)
Waarom ging NCSC-NL geen gesprek aan met mij? Naar eigen zeggen vinden ze problematisch dat het OpenBSD project in de zogenoemde 'full disclosure' methode gelooft (zie: https://www.openbsd.org/security.html).
Echter, het feit dat OpenBSD duidelijk omschrijft wat het project belangrijk vindt, zegt natuurlijk niet dat we idioten zijn die geen geheim kunnen bewaren. (hallo, wij beheren iedereen's openssh, en ook libcrypto op je Mac, en natuurlijk schitterende IKE/IPsec/RPKI/SMTP/BGP implementaties...)
Ik kan prima over NDAs onderhandelen en afspraken maken met mensen die een ons probleem aanmelden. Maar dan moet men wel een gesprek aanknopen. Het is mogelijk voor 'andersgelovigen' om productief met elkaar samen te werken.
Voor zover ik kan beoordelen heeft NCSC-NL enkel overlegd met een handjevol programmeurs. Verder lijkt het er op dat er geen enkele default-free network operator op de hoogte is gesteld.
In mijn optiek is bij RPKI/BGP securityproblemen een heel belangrijk aspect de deployment te coordineren tussen globale ISP / IXPs.
Er is niet nagedacht over hoe ISPs nieuwe software versies moeten kwalificeren alvorens ze uitgerold kunnen worden, en hoeveel tijd dit kost. Dit is kostbare tijd waarin allerlei ISPs vanaf maandag dus mogelijk kwetsbaar zijn.
Ook bestaan er verschillende operationele 'trust circles' specifiek voor het onderwerp Internet routing. NCSC-NL heeft hier blijkbaar geen weet van, en dus geen gebruik van kunnen te maken. Gemiste kans!
In deze casus lijkt het NCSC-NL onzorgvuldig gehandeld te hebben met mogelijk sensitieve informatie over kritieke Internet infrastructuur. Wat mij betreft niet voor herhaling vatbaar.
Met vriendelijke groeten,
Job _______________________________________________ NLNOG mailing list NLNOG@nlnog.net http://mailman.nlnog.net/listinfo/nlnog
NLNOG mailing list NLNOG@nlnog.net http://mailman.nlnog.net/listinfo/nlnog
participants (5)
-
Alex Bik -
Job Snijders -
niels=nlnog＠bakker.net -
Sabri Berisha -
Teun Vink