Volstrekt mee eens!

Frauders kunnen simpelweg een keypair op de naam van zo'n organisatie genereren en uploaden naar keyservers. Leuk dat je daar public keys kunt downloaden, maar die zul je ergens moeten verifiëren voordat je ze veilig kunt gebruiken. Een up-to-date public key beschikbaar gesteld op een https site van de betreffende organisatie is gewoon veel betrouwbaarder (mits je zeker weet dat de domeinnaam van die site van de betreffende organisatie is).

Daarbij is het niet uitlekken van kwetsbaarheden notabene in het belang van de betreffende organisatie zelf. Wat een onkunde (wellicht een uitnodiging voor full disclosure?) als je dan niet zelf jouw public key(s) betrouwbaar publiceert...

Dank je voor de reactie Erik.
Public Keys uit een keyserver moet je inderdaad volstrekt mijden. Je hebt geen enkele zekerheid of de identiteit van de public Key wel klopt. Meer zekerheid biedt een https-website waar de key is gepubliceerd, na controle van het uitgegeven certificaat en de domeinnaam die behoort aan de organisatie. Mijn public Keys worden in ieder geval niet geuploaded naar een keyserver.

Voor de meeste ambtelijke organisatie's geld dat je RD notificaties via het NCSC kunt/moet doen, die hebben gewoon netjes hun PGP publieke sleutel online staan en er zelfs een expire datum bij gezet.

Hebben ze wel een RD melding staan maar geen publieke sleutel: dan zou ik er voor kiezen om eea via het NCSC te spelen.

Het is heel logisch wat je hier zegt. Probleem echter is dat de regel van Responsible Disclosure van de organisatie juist vraagt dat je een kwetsbaarheid niet deelt aan een derde partij. Doe je dat wel, dan heb je juridisch een nogal groot probleem. Mocht een organisatie het doorsturen van zo'n kwetsbaarheid naar het NCSC goedkeuren, dan moet dat schriftelijk ook vast staan via de website van de gedupeerde organisatie. Anders zou ik er niet aan beginnen.

Je hoeft het RD ook niet te melden naar het NCSC, je kunt daar wel aanhangig maken dat in hun RD een PGP sleutel mist.
Of gewoon het contact formulier gebruiken en ernaar vragen ;-)

Mocht je twijfelen mbt rijksoverheids instantie's: altijd via het NCSC:
https://www.ncsc.nl/contact/kwetsbaarheid-melden
https://www.communicatierijk.nl/vakkennis/rijkswebsites/verplichte-richtlijnen/responsible-disclosure

Voor overige ambtelijke instantie's zoals gemeenten, kan het inderdaad verschillen. Maar dan zou ik persoonlijk gewoon contact zoeken en naar hun site verwijzen en daar informeren waar dan hun PGP sleutel gepubliceerd staat om te gebruiken en ter verificatie.

Ik werk al enige tijd bij overheden en dergelijke instantie's overigens ;-)
We zien je melding graag tegemoet zodat je ons helpt eea snel weer veilig te kunnen maken.

Als de TLS verbinding van de email op orde is, wat is dan het voordeel van PGP?

De kans dat je een full-reply krijgt zonder PGP is echt nagenoeg bij elke melding bij mijn ervaringen.

Welke van de -vaak meerdere- TLS verbindingen waarvan jij niet weet of die opportunistische encryptie gebruiken (dus zonder authenticatie) bedoel je? En gelukkig zijn alle systeembeheerders onderweg altijd 100% betrouwbaar. En tikfouten in het e-mail-adres van de ontvanger zijn natuurlijk ook uitgesloten.

Onbegrijpelijk dat, zo lijkt het, zelfs op security.nl veel mensen denken dat versleuteling het enige doel is (en dat het niet boeit wie de sleutel(s) heeft).

Dan verdient zo'n organisatie het dat je dat antwoord meteen -onder een pseudoniem- op de full disclosure maillijst post, en richting die organisatie liegt dat niet jij dat gelekt hebt.

Als ik mijn RD melding direct aflever op de smtp server van de organisatie zelf, dan zijn zij zelf verder verantwoordelijk voor alles wat erachter zit. Als dat niet te vertrouwen is, is dat een RD melding op zichzelf waard ;). Het spreekt voor zich dat ik TLS afdwing daarbij voor mijn verbinding.

Natuurlijk biedt PGP voordelen, maar vergeet niet ook de nadelen. De kans in grote bedrijven dat PGP helemaal niet
snel werkt is geen illusie: waarschijnlijk moet iemand de mail copy/paste naar een los systeem worden overzetten, omdat alle mailscanning op virussen etc onmogelijk is met PGP en je niet wilt weten wat er dan verpakt binnenkomt.
En is het RD kanaal ineens het enige kanaal met PGP? Dan weet ik wel hoe oud die software langzaam wordt en iemand moet die dus ook weer updaten voor jouw mailtje ;). Is het allemaal waard natuurlijk als je echt een 0-day hebt. Maar de meeste RD meldingen zijn toch niet van dat kaliber. En dat bevestig TS al: die PGP keys zijn zo oud, zonder dat iemand het ook ooit aangeeft (dus niemand gebruikt ze).

KISS (Keep It Simple) is ook nog steeds een motto in de security en PGP valt daar gewoon niet onder. E-mail is hoognodig toe aan een update, niet aan een PGP-patch.

p.s. Ik geef zelf overigens altijd de voorkeur aan een online formulier waar je het kunt achterlaten: hoef ik slechts de HTTPS verbinding te checken en is het daarna hun verantwoordelijkheid.

Inderdaad. Veel mensen hier lijken te denken dat het secuity team de godenzonen van de IT zijn, en dat volledige organisatie en alle IT afdelingen vragen "hoe hoog" als security zegt "spring" .

Dat is zelden het geval - Bij erg veel organisaties is security één van de vele IT afdelingen. En moet net als ieder ander werken met een standaard werkplek, en standaard mailvoorzieningen . En via een standaard aanvraagproces iets bij godsgratie van de afdeling communicatie op de organisatie website zien te krijgen.

Dus ja - wrang - maar het kan heel goed dat je óók als security teamlid geen unapproved software - zoals PGP - op je werklaptop krijgt , dat het mailplatform geen uitzondering voor je mag maken om onscanbare mail - zoals PGP - door te laten .

Het kunnen heel vermoeiende interne processen zijn wanneer je als team erg afwijkende eisen hebt qua werkplek en communicatie voorzieningen in een organisatie die voor 99.9% is ingericht op "normaal" kantoor automatiserings gebruik.
Daar kun je van alles van vinden - maar het is vaak de realiteit - evenzeer kun je lang niet alles over de kwaliteit van de IT en mensen afleiden uit de publieke website . Er kunnen ontzettend goede mensen zitten - die alleen niet gaan over de publieke webserver of de front-end html code .


Zoiets is praktisch altijd genoeg. Als je werkelijk denkt dat je iets meldt waarbij de hackers volledig meelezen op een platgehacked mailplatform - zoek dan een offline channel -bijvoorbeeld NCSC voor ongeveer de hele overheid .

Juist indien je een of meer redenen hebt voor een RD- (andere lezers: responsible disclosure) melding, is het mijn ervaring dat er meer mis is met de beveiliging van ook andere systemen van zo'n organisatie dan je aanvankelijk vermoedt en/of opmerkt. Het risico is dan groter dan gemiddeld dat anderen, met minder vriendelijke bedoelingen dan jij, al ongenodigd op andere systemen aan hun netwerk rondwaren. Dat soort types zitten nooit op jouw kattebelletje te wachten, en zullen er alles aan doen om te voorkomen dat jouw bericht de bedoelde persoon bereikt (daarbij zich mogelijk richting jou voordoend als security officer en jou op het verkeerde been zetten of zelfs voor hun karretje spannen). Bijv. een aangepast MX-record volstaat om jouw mail bij een derde te laten belanden (dat de verbinding tussen jouw mailserver en die van de ongenode gasten versleuteld is, helpt dan geen zier). E2E (End-to-End) encryptie met een grondig geauthenticeerde verantwoordelijke binnen die organisatie vind ik altijd te prefereren. Dit is ook in jouw eigen belang: als jouw kattebelletje in verkeerde handen valt en de aanvallers daarvan profiteren, zal de organisatie jou minder aardig vinden dan je misschien had gehoopt/verwacht (en wellicht weten hun advocaten vervolgens wel raad met jou).

Allemaal goede argumenten, maar het verzoek van de TS is juist om een veilig kanaal te faciliteren en geen half werk te leveren. Als een organisatie daar PGP voor wil gebruiken, hou die PGP-omgeving dan up-to-date.

Stap anders over op een alternatief zoals Signal (of Threema etc.), of zet alle vertrouwelijke info in een bijlage die je versleutelt met desnoods 7-Zip (AES cipher natuurlijk) waarbij je de sleutel via een hoogtswaarschijnlijk veilig kanaal met de -gedubbelchecked- juiste persoon uitwisselt. Als zo'n bijlage wordt geblokkeerd op de mailserver, zijn er allerlei trucs denkbaar (zoals die versleutelde zipfile BASE-64'en en het resultaat achter een stuk leesbare tekst in een .txt bestand plakken, en dat .txt bestand als bijlage meesturen. De versleutelde zipfile na 4-8 bytes splitten en aan de andere kant met "copy /b part1 + part2 file.zip" aan elkaar plakken, werkt vaak ook).

Eens, maar zie mijn vorige antwoord.

Dat ondersteunt maar één richting, serieuze organisaties die gewaarschuwd worden willen vaak meer weten (hoe heb je dit ontdekt, waarom onderzocht je hun systeem, reproduceren lukt vaak niet meteen etc).

Maar toegegeven, als je via PGP authenticeert en versleutelt is het nog maar de vraag of de public key echt van de bedoelde persoon is, of die persoon binnen de organisatie geautoriseerd is om dit soort problemen af te handelen, of die persoon geen dubbele agenda heeft en of diens private key niet in verkeerde handen is gevallen. Het is verstandig om de identiteit en autorisaties van de gesprekspartner via meerdere kanalen te valideren, maar 100% zekerheid krijg je natuurlijk nooit.

Prachtig verwoord.


Zolang je de regels van de andere partij volgt omtrent het melden van een RD is het niet jouw verantwoordelijkheid wat er bij transport mee gebeurd. Jij hebt de regels gevolgd als hun beleid of infra lek als een mandje is ook bij de ontvangst van een RD dan is dat potentiele datalek ook hun verantwoordelijkheid. Geen enkel bedrijf dat je dan kan aanklagen of legal afdeling die ook maar zich hier aan durft te wagen. (zie je de PR nachtmerie al voor je?)

Ga je echter zelf eisen eraan stellen tja dan is het beter dat je de melding laat voor wat het is het is. Je gaat dan je taak voorbij van het enkel melden, informeren. En vind je het dan toch zo belangrijk dat het op een bepaalde manier moet en is de melding zo dringend in jouw ogen dan bel je naar ze of je mailt van te voren dat je graag een RD melding wilt delen maar wegens X Y niet nu kan.

En zo kort mogelijke boodschap geen instructie boekwerk hoe het te fixen je mag aannemen dat ze die kennis zelf of hebben of weten te vinden. Anders heeft die RD ook niet veel nu als ze uberhaubt geen kennis hebben van zaken.
(Hoi bij deze wou ik een een RD melding maken echter jullie PGP keys zijn verouderd. Hoor graag als dit opgelost is zodat ik de melding kan sturen. Of indien mogelijk een ander kanaal voor de melding in de tussentijd. MVG.)


Het is in het zelfde straatje als email, domain abuse meldingen je komt in de bedrijfsadministratie traject terecht en zodra er resources beschikbaar zijn zal er naar gekeken worden. Voor elke goed geformuleerde RD in een grote organisatie heb je er 10 als niet meer zijn die opgesteld zijn door iemand die werkelijk waar niks snapt van algemene rapportering, RD of laat staan cybersecurity. (Hoi ik zie dat je versie X gebruikt er is tegenwoordig al een versie Y)
Zulke pareltjes heb je er ook tussen al die meldingen zitten.

En uiteindelijk moet iemand van vlees en bloed naar al die meldingen kijken en beoordelen of het werkelijk ook nog tijd waard is buiten de quick scan. Dus de meeste verantwoordelijke zullen KISS absoluut waarderen.
Als iemand inbelt en zegt dat er een potentieel lek gaande is in onze infra dan ben ik vele male sneller geneigd om die melding prioriteit te geven dan als ik eerst een checklist aan eisen moet doorlopen van de andere partij waar ik nog helemaal niks van af weet laat staan of ze uberhaubt legitiem zijn.

Er zit een groot verschil tussen een simpelweg een RD melding maken als buitenstaander of security consultant rol op je nemen. Verwar ze niet met elkaar want het kost alle partijen meer tijd dan het waard is. En als je het tweede ongevraagd doet beland je communicatie al heel gauw in de prullenbak hoe goed je intenties ook moge zijn als bedrijf moet je ook prioriteiten stellen en je minuten verdelen over taken.

Precies, dat is een veel betere oplossing!

Dat hele PGP gedoe dat is leuk als je een hackertje bent maar voor een normaal bedrijf is daar in hun standaard
omgeving niks mee te beginnen. Niemand gebruikt dat, nergens is software ervoor standaard geinstalleerd in de
productie omgeving, de bekende platformen ondersteunen het niet.
Als er "bij ons" een PGP gecodeerd mailtje zou binnenkomen op een algemeen mail adres is de kans heel groot dat
er niks mee gebeurt omdat niemand weet wat je er mee moet, en niemand de mogelijkheid heeft om zelf even wat
software te downloaden en installeren. De afhandeling wordt op zijn minst vertraagd en waarschijnlijk denkt men
"zal wel phishing zijn ofzo, deleten". Dus hebben we ook geen PGP sleutels.

Dat aspect snappen de melders natuurlijk niet omdat dit een totaal andere wereld is dan die van henzelf.

De vier bij ons werkzame Windows systeembeheerders, ervaren mensen, hebben ieder onder Outlook een OpenPGP-plugin geïnstalleerd. Met enige regelmaat ontvangen of verzenden zij beroephalve PGP-codeerde mail. Mochten de andere medewerkers onverwacht een PGP mail van buiten ontvangen, dan weten zij daar ook wel raad mee.

https://www.openpgp.org/software/


Gebruik van encryptie, met name PGP, kampt met een imagoprobleem Ondertussen maakt de grote massa massaal gebruik van HTTPS in webbrowsers en van het Signal end-to-end encryptie protocol, dat ook in WhatsApp is ingebouwd. WhatsApp is heel populair, zowel onder de jeugd als bij ouderen. Het is dus maar net hoe je het bekijkt.

De cluster van Linux servers die hier draait, zou zonder de uitvinding van PGP niet eens kunnen functioneren.

Ik ben het eens met je verhaal, maar die laatste zin vereist de nodige nuance. Goed sleutelbeheer vereist kennis en strakke processen. Het zou de eerste keer niet zijn dat ik een private key toegestuurd krijg na mijn vraag de public key op te sturen. Laat staan dat sleutelroulatie, least privilege, PGP en cryptografische kennis, de aanwezigheid van de juiste software e.d. geregeld zijn. Ga daar vooral niet van uit, ook al zie je een PGP sleutel op de website.

Het probleem is naast technisch ook administratief. Iemand laat de publieke sleutel op de corporate website plaatsen en gaat naar een andere functie of naar ander bedrijf. Gevolg: niemand besteed hier verder aandacht aan. Sterker nog, waar is die private key eigenlijk opgeslagen? Kijk naar de meldingen die af en toe de kranten halen over verlopen public key certificaten, of het laten verlopen van domeinnamen. Allemaal geen moeilijke acties om uit te voeren, maar veel mensen begrijpen niet dat een bedrijf met 50.000+ man personeel niet aan alles denkt, of alles even goed is gedocumenteerd, of overgedragen, of belegd, of zit te wachten op jouw goede bedoelingen omdat ze al overlopen van het werk, of is geautomatiseerd zodanig dat je 3 maanden van tevoren een berichtje krijgt van sleutels die gaan verlopen. Zo volwassen zijn organisaties niet.

Dit praat niet goed dat zaken niet goed geregeld zijn, maar dit soort zaken hebben niet de hoogste prioriteit. Sterker nog, vanuit een managementoptiek is dit niet belangrijk. Misschien een leuke presentatie om eens te bekijken van Patrick Miller op de S4 conferentie: https://www.youtube.com/watch?v=uVVlDOxE1mE. Sommige zaken formuleert hij wat gechargeerd, maar zijn verhaal is voor veel security werknemers denk ik erg herkenbaar. Niemand ligt wakker van een PGP sleutel die niet is bijgewerkt, zelfs beheerders niet. Ze hebben mailboxen waar dagelijks tientallen zo niet honderden mails op binnen komen. Die ene mail per kwartaal die op rd@companyname.com binnen komt... het zal wel. Niet goed, maar dat is de dagelijkse realiteit, die niet zal veranderen. Niet iedereen deelt jouw passie voor RD ;-)

Precies. Niemand zit te wachten op PGP.
Je kunt PGP wel als je standaard werkwijze poneren maar de rest van de wereld zal je vragen aankijken en zich afvragen waarom je niet iets moderns gebruikt.
Ik zou zeggen maak een invulformulier op je (met https beveiligde) website en zet daar het backend achter wat je zelf het liefste ziet.
Dan kan iedereen het gewoon indienen en kun je het verwerken zonder eerst PGP plugins te moeten gaan zoeken.
En het certficaat op de website wordt al vernieuwd dus gedoe met verlopen keys of het bedenken van een eigen mechanisme om de public key aan de andere kant te krijgen heb je ook niet.