Attachments vs links mailen

[CAPSLOCK2000]

In het kader van: "Geen dogma's, trek alles in twijfel" wil ik even tegen een heilig huisje schoppen om te kijken hoe stevig het nog staat.

Conventionele wijsheid is dat het mailen van bestanden gevaarlijk is en dat het dus verstandig is om bepaalde bestandstypes te blokkeren. In plaats daarvan wordt aangeraden om het bestand te uploaden naar een of andere filesharing website en dan een link te sturen.
Dit wordt bijvoorbeeld aangeraden (zo niet afgedwongen) door Microsoft, bv op de pagina Blocked attachments in Outlook.

Ik kan dat standpunt tegenwoordig niet meer goed uitleggen op grond van veiligheid. Let op, ik heb het alleen over de veiligheid. Andere nadelen van attachments en e-mail, zoals de beperkte bestandgrote, zijn even niet relevant. Ze zijn niet onbelangrijk maar maken de discussie te breed. Het gaat nu dus alleen om bestanden direct mailen vs het mailen van een link naar een bestand.

Het oude advies is gebaseerd op vrees dat een attachment is besmet met malware die (al dan niet automatisch) door de mail-client van de gebruiker wordt uitgevoerd en dat webbrowsers veiliger zijn. Een bijkomende factor is dat het lastig is om de afzender van een e-mail te controleren.

Hoe relevant is dat tegenwoordig nog?

- Een mailclient zou natuurlijk niet zomaar attachments moeten openen. Dat is nu al 25 jaar bekend en ik vind dat we er van uit mogen gaan dat mailclients dat niet meer doen.

- Steeds meer mensen lezen hun mail via webmail, in hun browser dus. Het idee dat een browser veiliger is doet er daarmee niet meer toe.

- Doordat moderne websites bol staan van javascript is het nagaan wat een website doet (en of er troep in zit) veel moeilijker dan de inhoud van een e-mail controleren.

- Websites zijn dynamisch, je kan ze niet eenmalig keuren want ieder volgende bezoek kan de site helemaal naders zijn (in tegenstelling tot e-mail).

- Het controleren van de afzender van een mail is makkelijker geworden door technieken als SPF en DKIM, PGP en SMIME

- Het is veel lastiger om te controleren wie de eigenaar/afzender is van een bestand op een grote filesharing site. Als je een link naar Dropbox of Onedrive krijgt dan wijst de naar het domein van de hostende partij. De halve wereld is klant bij die bedrijven. Je kan je gebruikers dus niet meer vertellen dat ze naar de domeinnaam moeten kijken om te zien wie de eigenaar van een website is. Soms wordt de naam van de klant als subdomein opgenomen maar dat is te lastig om uit te leggen aan gebruikers.

- Iedereen heeft een virusscanner nodig om bestanden/sites te controleren die je met je webbrowser controleert. Ook e-mails worden gecontroleerd en ik zie niet in waarom dat anders of minder veilig is. Vanwege de gecontroleerde interface is het alleen maar makkelijker om alle mail goed te controleren.
Daarbij kun je ook op de mailserver al een virusscanner draaien en ingrijpen voor de mail uberhaupt bij de gebruiker komt.

- Het is heel gebruikelijk geworden om bestanden te zippen of van extensie te veranderen om ze toch te mailen. Gebruikers kennen dat en zullen zo'n bestand zelf terughernoemen/unzippen. Deze vorm van bescherming (file extensies blokkeren) is dus maar heel beperkt.

- Mail is eenvoudiger te beheersen dan websites. Alle inkomende mail gaat immers via je eigen mailserver. Daar kun je controles uitvoeren en zeker weten dat alle inkomende mail gecontroleerd wordt. Daarnaast is het voor je gebruiker niet mogelijk om op een andere manier bij hun mail te komen. Die staat alleen op jouw mailserver en je gebruikers kunnen niet buiten je eigen systemen omgaan om daar bij te komen. Ze kunnen wel een mailclient op een ander apparaat installeren maar daarmee kunnen ze niet de filters op de mailserver omzeilen.

- Om iets vergelijkbaars met websites te doen heb je een proxy nodig maar dat moet je actief instellen op de apparaten van je gebruikers. In je eigen netwerk kun je dat nog eenvoudig afdwingen door alleen toegang tot internet te geven via die proxy maar dat wordt snel lastig af te dwingen zodra mensen mobiel werken of vanaf thuis of met hun eigen byod apparaten.

- In theorie kunnen gebruikers wel verleid worden om een extra mailbox te configureren op een mailserver van een aanvaller maar dat lijkt me nog best lastig. Als je ze zo ver hebt dan kun je ze ook wel eenvoudigere opdrachten geven (zoals "klik op deze link").


- Onze data staat steeds meer online in plaats van op onze eigen computer. Een webbrowser hacken is daarmee gevaarlijker aan het worden(?) dan een mailclient/pc hacken.

- Er is ook nog een advies dat zegt dat je niet op links in je e-mail moet klikken. Dat botst regelrecht met het advies om links te mailen in plaats van attachments.

- Verder wil ik niet onbenoemd laten dat er nog steeds e-mail via onversleutelde verbindingen wordt gestuurd. Maar webbrowser ondersteunen ook nog steeds plain text http zonder te mokken al is het moeilijker om daar misbruik van te maken. Dit wil ik voor deze discussie buiten beschouwing laten.

- Ten slotte is ondersteuning voor MFA in mailprotocollen niet heel erg breed, maar dat is niet relevant wanneer de gebruiker er voor kiest om een attachment of link te openen. Ook dat wil ik nu dus buiten beschouwing laten.

Dus, hoe staan jullie er in?
Is het nog steeds nodig om e-mail attachments grotendeels te blokkeren?
Of is dat tegenwoordig een cargo-cult ritueel?
Is het een automatisme dat het mailen van lnks beter is dan het mailen van attachments?
Welke veiligheidsrisico's zitten er aan attachments die je niet hebt als je een link opent met je browser?
Of is dit geen heilig huisje meer maar een open deur die ik nog niet had gezien?

[Standeman]

Ik vind eigenlijk dat beiden, zowel linkjes als attachements, een no-go zijn. Alles kan gespoofed zijn, niet alleen from adressen, maar ook URL's. Zijn het geen url-shortners, dan wel gelijkende adressen met homograven.

Ik klink dus nooit zelden op links of attachements. Als ik naar de website toe wil, tik ik zelf wel het adres in de URL balk in

[Reptile209]

Gecombineerd voor- en nadeel: als je een bestand mailt, weet je zeker dat alle ontvangers op dat punt dezelfde versie hebben. Maar als het een 'levend' document is, dan is dat juist weer een nadeel, omdat latere wijzigingen niet worden meegenomen en je periodiek een nieuwe versie moet gaan rondsturen.

Voor mij wel een verschil van versturen afhankelijk van de ontvanger(s): intern doe ik een (sharepoint) link (of direct via Teams), maar extern kan/mag/werkt dat meestal niet. Bovendien wil je bij externe ontvangers soms ook wel kunnen terugzoeken welke exacte versie van een document je verstuurd hebt, dus dan is een bijlage weer handiger.

Tot slot: verzenden via externe partijen (à-la dropbox) is niet altijd een optie, ivm privacy, serverlocatie, enz. Maar feitelijk is dat via mailservers buiten beheer van je eigen organisatie niet anders.

[Qwerty-273]

CAPSLOCK2000 schreef op vrijdag 31 maart 2023 @ 13:27:
Ik kan dat standpunt tegenwoordig niet meer goed uitleggen op grond van veiligheid. Let op, ik heb het alleen over de veiligheid. Andere nadelen van attachments en e-mail, zoals de beperkte bestandgrote, zijn even niet relevant. Ze zijn niet onbelangrijk maar maken de discussie te breed. Het gaat nu dus alleen om bestanden direct mailen vs het mailen van een link naar een bestand.

Het is een zijstraat, maar mail is niet bedoeld voor binaire data. Het is tekst, en vandaar dat je dan ook base64 encodering ziet op het moment dat je wel binaire data wilt gaan mailen. Nu leven we in 2023 maar het voegt nog steeds extra data toe aan de data die eigenlijk verstuurd moet worden - juist door de encoding. Extra bandbreedte etc etc.

Verder op het gebied van veiligheid, een attachment gat op moment A (verzenden/ontvangen) door scanners etc. En wordt daarna met rust gelaten tot het moment dat je iets opent en dan zal een lokale scanner er zijn oog op laten schijnen. Als het een 0-day betreft, dan hebben de scanners op het pad van transport nog niets in de gaten en bestempelen ze de data als ok. Terwijl een scan een uur/dag later daar een andere mening over kan hebben.

Een link is in dat opzicht handiger omdat je (als IT orga) dan meer controle hebt op het moment dat je daadwerkelijk de data opvraagt. Komt het van een betrouwbare host (al kan iedereen tegenwoordig wel wat bij MS of andere cloud parkeren), transparante proxies die downloads scannen, etc. etc. Je kan wat meer controle uitoefenen op bronnen dan wanneer de payload via de mail al binnen is gekomen.

Een andere overweging is of je mail service wel de plek is om binaire data in op te slaan. En dan kom je op backup/restore sla's terecht etc. en eventuele data retentie of andere regelgeving waar je als bedrijf aan moet voldoen.

[CAPSLOCK2000]

Standeman schreef op vrijdag 31 maart 2023 @ 13:45:
Ik vind eigenlijk dat beiden, zowel linkjes als attachements, een no-go zijn. Alles kan gespoofed zijn, niet alleen from adressen, maar ook URL's. Zijn het geen url-shortners, dan wel gelijkende adressen met homograven.

Ik klink dus nooit zelden op links of attachements. Als ik naar de website toe wil, tik ik zelf wel het adres in de URL balk in

Hoe doe jij het als je een bestand met mensen wil delen? Zeker als dat relatief onbekende zijn (dus geen collega's die samen een vertrouwde fileshare hebben)?

Een korte domeinnaam intikken gaat nog wel maar niet als het een automatisch gegeneerde link is van 500 random characters.


Helemaal geen bestanden delen is natuurlijk geen optie. Op enig moment zal je data moeten accepteren zonder dat je (realistisch gezien) kan controleren wie de afzender is en of de mail niet is gemanipuleerd.
In een ideale wereld zoek je dan een andere oplossing maar daar wonen wij niet.

[CAPSLOCK2000]

Reptile209 schreef op vrijdag 31 maart 2023 @ 13:57:
Gecombineerd voor- en nadeel: als je een bestand mailt, weet je zeker dat alle ontvangers op dat punt dezelfde versie hebben. Maar als het een 'levend' document is, dan is dat juist weer een nadeel, omdat latere wijzigingen niet worden meegenomen en je periodiek een nieuwe versie moet gaan rondsturen.

Voor mij wel een verschil van versturen afhankelijk van de ontvanger(s): intern doe ik een (sharepoint) link (of direct via Teams), maar extern kan/mag/werkt dat meestal niet. Bovendien wil je bij externe ontvangers soms ook wel kunnen terugzoeken welke exacte versie van een document je verstuurd hebt, dus dan is een bijlage weer handiger.

Dat zijn op zich legitieme overwegingen maar omdat ze niet over security gaan wil ik ze nu buiten de discussie houden.

Tot slot: verzenden via externe partijen (à-la dropbox) is niet altijd een optie, ivm privacy, serverlocatie, enz. Maar feitelijk is dat via mailservers buiten beheer van je eigen organisatie niet anders.

Met de juiste contracten is het (in ieder geval juridisch gezien) wel te doen en is er inderdaad geen fundamenteel verschil tussen mailserver of een fileserver. Je data staat op de computer van iemand anders en zowel zender als ontvanger hebben geen volledige controle. Wat dat betreft zie ik dus geen duidelijke reden om voor het een of het ander te kiezen.
In beide gevallen kan je er voor kiezen om het in eigen beheer te doen als je er geen derde partij tussen wil hebben (bv omdat het juridisch te lastig is, of omdat je onderling bestanden van 1GB wil kunnen mailen).

Pragmatisch gezien heeft mail het voordeel dat mensen niet zomaar even een nieuwe mailaccount aanmaken en in hun mailclient configureren om een enkel bestandje te mailen. Met Dropbox-achtige sites doen ze dat wel.

[CAPSLOCK2000]

Qwerty-273 schreef op vrijdag 31 maart 2023 @ 14:04:
Het is een zijstraat, maar mail is niet bedoeld voor binaire data.

Die zijstraat laat ik bewust buiten beschouwing omdat het niet over security gaat. Gebruikers hebben hier toch geen boodschap aan.

Verder op het gebied van veiligheid, een attachment gat op moment A (verzenden/ontvangen) door scanners etc. En wordt daarna met rust gelaten tot het moment dat je iets opent en dan zal een lokale scanner er zijn oog op laten schijnen. Als het een 0-day betreft, dan hebben de scanners op het pad van transport nog niets in de gaten en bestempelen ze de data als ok. Terwijl een scan een uur/dag later daar een andere mening over kan hebben.

Daarvoor zal je een 'on access' virusscanner nodig hebben op het device van de gebruiker. Die je heb toch nodig. Een virusscanner op de mailserver is extra, geen vervanging voor een lokale scanner.,

Een link is in dat opzicht handiger omdat je (als IT orga) dan meer controle hebt op het moment dat je daadwerkelijk de data opvraagt. Komt het van een betrouwbare host (al kan iedereen tegenwoordig wel wat bij MS of andere cloud parkeren), transparante proxies die downloads scannen, etc. etc. Je kan wat meer controle uitoefenen op bronnen dan wanneer de payload via de mail al binnen is gekomen.

Ik zie geen verschil tussen een webbrowser die on-demand een pagina opvraagt die dan eerst wordt gecontroleerd of een e-mail client die een mail opvraagt die dan ook eerst wordt gecontroleerd.

[Orion84]

Ik denk dat je hier ook wel een belangrijk onderscheid moet maken tussen interne mailwisselingen (dus tussen collega's) en externe mails (B2B / B2C).

Dat je intern beter linkjes naar sharepoint/onedrive/etc. kan gebruiken in plaats van eindeloos kopietjes rondmailen is in veel gevallen wel een valide punt denk ik.

[CAPSLOCK2000]

Dat je intern beter linkjes naar sharepoint/onedrive/etc. kan gebruiken in plaats van eindeloos kopietjes rondmailen is in veel gevallen wel een valide punt denk ik.

Is dat vanuit het oogpunt van veiligheid of uit het oogpunt van handig samenwerken?

Dat laatste wil ik nu even buiten beschouwing laten want dat is afhankelijk van de omstandigheden. Die voordelen zitten (denk ik) vooral in het online editten en ingebouwd versiebeheer, niet in de veiligheid.

In het algemeen is er natuurlijk wel wat voor te zeggen dat je documenten liever op 1 plek bewaard want iedere kopie zal je weer moeten beveiligen, maar dat zijn specifieke omstandigheden, onder andere omstandigheden hebben andere oplossingen wellicht de voorkeur.

[ Voor 21% gewijzigd door CAPSLOCK2000 op 31-03-2023 15:51 ]

[Qwerty-273]

CAPSLOCK2000 schreef op vrijdag 31 maart 2023 @ 14:39:
Ik zie geen verschil tussen een webbrowser die on-demand een pagina opvraagt die dan eerst wordt gecontroleerd of een e-mail client die een mail opvraagt die dan ook eerst wordt gecontroleerd.

Het verschil zit dan meer in het feit dat een transparante proxy door een andere afdeling bijgehouden wordt en er meer monitoring/druk opligt binnen de organisatie als deze niet meer update, dan een enkel eindgebruiker device waar van alles mis kan zijn door welke reden dan ook en IT eerder een klacht van de gebruiker als actie moment neemt dan een monitoring alert dat een end-device out-of-date is.

Maar een moderne virusscanner kijkt niet alleen naar een match in een definitie tabel maar ook naar het gedrag als iets uitgevoerd wordt. Verdacht gedrag kan je ook blokkeren ook al is de uitgevoerde code nog niet bekend/verwerkt door je antivirussoftware leverancier.

Veder zouden de twee producten (client software en de gekozen server side scanner of dat nou op mail transport of een proxy niveau is) een andere engine moeten gebruiken. Hier mee verklein je de kans dat een specifieke engine bug niet je omgeving bloot stelt.

[BytePhantomX]

Security benader je m.i. vanuit een beperkte invalshoek, namelijk malware.

Een ander perspectief is vertrouwelijkheid en integriteit. Alhoewel email tegenwoordig vaak versleuteld is, heb je geen garantie dat jouw mail alleen bij de ontvanger terecht komt. Via een portal kun je dat beter afdwingen, door bijvoorbeeld mfa af te dwingen met een geregistreerd telefoonnummer. Ook houd je meer controle omdat je kan zien wie en wanneer het document heeft ingezien, of het is gedownload en je kunt het document terugtrekken.

Bovenstaand is m.i. de belangrijkste reden dat ik vanuit security perspectief nog terughoudend ben om bijlages te mailen. En ook een reden dat bijvoorbeeld emailen van privacy gevoelige data in de zorg niet is toegestaan.

T.a.v. malware geef ik je gelijk. Zou geen verschil in moeten zitten. Alhoewel je vaak bij bedrijven zal zien dat er dubbele filetering plaats vind op malware. Op de mail server en op het device. En in dit soort gevallen is meer controles vaak beter, maar niet heilig.

[CAPSLOCK2000]

BytePhantomX schreef op vrijdag 31 maart 2023 @ 16:01:
Security benader je m.i. vanuit een beperkte invalshoek, namelijk malware.

Een ander perspectief is vertrouwelijkheid en integriteit.
<knip>
T.a.v. malware geef ik je gelijk. Zou geen verschil in moeten zitten.

Goede punten. Ik probeer vooral zoveel mogelijk argumenten op tafel te krijgen om zo op de juiste punten de juiste beslissingen te nemen.

We hebben met z'n allen nog wel eens de neiging om vast te houden aan de best practices van het verleden. Dat komt al snel neer op steeds meer verbieden. Vroeg of laat blijft er niks meer over of maak je het onnodig moeilijk en complex.

De concrete aanleiding van de vraag is een beslissing nemen over welke bestandsformaten we blokkeren op onze mailserver. Die beslissing is ooit genomen op grond van malware, vandaar de focus die ik daar op heb. Je hebt helemaal gelijk dat ik daar misschien een beetje te veel op focus, maar ik probeer de juiste proporties te vinden. Het voelt een beetje onzinnig om super streng te zijn op e-mail attachments terwijl er net zo veel risico zit in het lukraak klikken op linkjes in e-mail.

Vandaar dat ik even opnieuw over het probleem probeer na te denken zodat we onze energie op de juiste punten richten.

We kunnen het ook niet alleen want we hebben alleen controle over wat we zelf verzenden/delen, niet over wat de rest van de wereld onze kant op stuurt.

Er zijn goede redenen om geen bestanden te verspreiden via e-mail maar malware hoort daar IMHO steeds minder bij, relatief gezien. Uiterard is alles afhankelijk van je omgevingen en je behoeftes.

[ Voor 9% gewijzigd door CAPSLOCK2000 op 31-03-2023 16:45 ]

[Orion84]

CAPSLOCK2000 schreef op vrijdag 31 maart 2023 @ 15:00:
[...]

Is dat vanuit het oogpunt van veiligheid of uit het oogpunt van handig samenwerken?

Beide. Attachments mailen geeft namelijk ook een extra risico dat je 'm per ongeluk naar de verkeerde mailt en zeker als dat een externe ontvanger is, is dat wel een dingetje. Een externe ontvanger heeft doorgaans geen toegang tot interne file share oplossingen.

Daarnaast speelt bij interne mails het punt van "niet op linkjes in een mail klikken" een stuk minder natuurlijk, mits je je e-mailomgeving zo hebt ingericht dat je zeker weet dat een interne mail ook echt intern is en niet gespoofed. Dus wegen de praktische voordelen al snel op tegen dat potentiële veiligheidsnadeel wat je noemt.

Want je kan het wel puur over veiligheid willen hebben, maar uiteindelijk is het altijd een afweging natuurlijk

[ Voor 32% gewijzigd door Orion84 op 31-03-2023 17:51 ]

[BytePhantomX]

Als het puur is om malware, vraag ik me af waarom je het vrij zou geven. Zijn er echt business cases, zijn jullie nu heel streng, wordt er veel omheen gewerkt?

Je argumenten zijn niet gek, maar linksom of rechtsom klinkt het toch als een verzwakking.

[S.McDuck]

Er zijn al een aantal antwoorden voorbij gekomen die hiermee te maken hebben maar ik wil toch ook wel een gooi doen.

Zelf denk ik dat je zelf de vraag moet stellen wat wil je bereiken met de maatregel voor email:
Is het intern of extern?
Is het veiligheid/security?
Wat is het niveau van je organisatie?

Dus welke maatregelen heb je in place en waar wil je de organisatie tegen beschermen. Een email is altijd een risico. De zender kan gehackt zijn, er kan malware inzitten het kan phishing zijn etc.. Denk aan spamfilter, Antivirus, Dkim/spf/dmarc.
Of is meer het om integriteit en bestandsdeling te reguleren en zitten we ook op identity & access? Dan gaan we richting bv sharepoint oplossingen en linksharing naar vertrouwde omgevingen.
Een datalek door verkeerde ontvanger(s) is vervelend maar met gevoelige data wordt naar en met attachment is nog ingewikkelder. Maar hoe voorkom je de menselijke factor? Een 4 ogen pricipe voor email is ook wel apart en een DLP oplossing is best wel ingewikkeld en next gen.

Met alle manieren van toegang die er tegenwoordig zijn is het beveiligen ook een stuk lastiger geworden. Hebben we het over netwerk, data of identities om maar wat te noemen. Dat zal dan ook de mate en soort security maatregelen bepalen. Voor de ene organisatie is het belangrijk om op malware te scannen, de andere zal meer op DLP en labelling zitten.

Ik denk niet dat je tegen heilige huisjes aanschopt of open deuren intrapt maar laat zien dat beveiligen complex en maatwerk is. Er is geen standaard oplossing imo.

[CAPSLOCK2000]

Bedankt voor alle reacties dusver.
Ik ben inderdaad niet op zoek naar een simpel "ja/nee" antwoord maar meer naar argumenten die je mee moet nemen om tot een goed oordeel te komen. Daarnaast ben ik gewoon geinteresseerd in hoe jullie bepaalde aspecten wegen en op welke gronden.

Ik ben ook niet op zoek naar de "beste" oplossing of een alternatief voor e-mail. We krijgen nu eenmaal mailtjes met bestanden er aan en moeten nu regelmatig vragen om het bestand op een andere manier te sturen. Als de zender het bestand vervolgens op een vage filesharingsite zet en ons verkorte link stuurt denk ik niet dat we daar beter van worden.

Bij het schrijven van de post had ik vooral externe communicatie in gedachte waarbij je geen gedeelde resources of (controleerbaar) vertrouwen hebt tussen de communicatiepartners. Bv alle zakelijke partners die we hebben die ons regelmatig bestanden sturen met handleidingen, licentievoorwaarden, rekeningen, rekenmodellen, ontwerpen, offertes, etc..

Het lijkt me beter om het topic te vernauwen tot externe communicatie want intern zijn er inderdaad zoveel meer en betere opties dat bestanden mailen nog maar weinig voorkomt.

Bij gesprekspartners merk ik regelmatig enige starheid en vasthouden aan regels van vroeger omdat ze zelf niet kunnen uitleggen waarom zo'n regel ooit is ontstaan. Dan kun je ook niet bedenken wanneer een regel niet meer nodig is of niet meer proportioneel is. Daarom hebben wij een (bij wijze van spreken) een ridder met een harnas en een zwaard om onze paardenstal te beveiligen terwijl iedereen met de auto of de fiets naar z'n werk komt. Wordt onze organisatie veiliger van het weghalen van die ridder? Nee. Maar met het salaris kunnen we andere dingen doen die meer zin hebben.

Als je maximale veiligheid wil moet je in een grot gaan zitten zonder computer. De organisatie waar ik voor werk is heel open en heeft (relatief) weinig geheimen en het is haast onmogelijk om dingen af te dwingen. Er is hier veel zelfstandigheid en zelfredzaamheid en geld en kennis om dingen zelf te regelen buiten IT om. Security heeft over het algemeen niet de hoogste prioriteit en er zijn weinig manieren om dingen af te dwingen.
De wenselijkheid daarvan is een discussie voor een andere topic. Als ik iets wil bereiken moet ik kunnen uitleggen dat het noozakelijk en proportioneel is.

Ik streef dus niet naar maximale veiligheid maar naar het beste compromis van maatregelen. De meeste bangs per buck. Minder regels is beter. Minder restricties is beter. De regels die er wel zijn moeten effectief zijn en op elkaar afgestemd.

Uiteindelijk speelt er meer dan alleen technische veiligheid en moeten er verschillende belangen worden afgewogen. Om die afweging te maken moet je de maatregelen wel in het juiste vakje stoppen. Blokkeer je attachments om virussen tegen te houden of om datalekken te voorkomen? Pas als je het doel weet kun je beoordelen of zo'n maatregel efficient is. (Een maatregel kan meerdere doelen hebben maar die moet je dan apart beoordelen). Vanuit security moet ik niet proberen om andere aspecten mee te wegen. Vanuit security geef ik bv niks om reputatieschade want dat kan ik toch niet goed beoordelen. Daar maken de mensen van Marketing zich wel zorgen om en die geven weer niks om virussen want daar hebben zij geen verstand van.

PS. Ik ben zelf natuurlijk ook niet immuun voor blinde vlekken en vastgeroest denken.

[CAPSLOCK2000]

BytePhantomX schreef op vrijdag 31 maart 2023 @ 23:02:
Als het puur is om malware, vraag ik me af waarom je het vrij zou geven. Zijn er echt business cases, zijn jullie nu heel streng, wordt er veel omheen gewerkt?

Je argumenten zijn niet gek, maar linksom of rechtsom klinkt het toch als een verzwakking.

Als je alleen naar e-mail kijkt is het inderdaad een verzwakking. Daarom dat ik het afweeg tegen het alternatief: linkjes mailen. Hoe strenger we zijn op attachments hoe meer linkjes er worden gemailed. Ik heb tegenwoordig liever attachments dan links.

We zijn op de meeste punten totaal niet streng en nog wordt er aan alle kanten omheen gewerkt waarbij ik met die oplossingen meer problemen heb dan met het oorspronkelijke probleem (e-mail attachments).
Het voorstel dat ik nu beoordeel is overigens niet om alle attachments toe te staan maar om 150 extensies toe te voegen aan de lijst met verboden bestandsextensies die toch al niet kort is. Ik heb liever dat aanvrager een virusscanner installeert, daar schieten we veel meer mee op.

(Het hele verhaal is uiteraard veel groter, voor de discussie hier op Tweakers heb ik een enkel draadje losgetrokken en gedestileerd tot "attachments vs links").

[BytePhantomX]

Door het zo te versimpelen verlies je de nuance en de context. Juist met security is dat m.i. van cruciaal belang om principiële discussies te voorkomen.

In deze is het wel, is er behoefte om dergelijke bestanden uit te wisselen, dan kunnen het wel verbieden, maar worden er toch andere oplossingen gevonden. Dan moet je ook in staat zijn om die te verbieden en dat is vaak niet haalbaar.

Deze discussie zou ik persoonlijk niet voeren. Doen als het praktisch haalbaar is en geen gedoe oplevert. Vooral niet doen als dat wel het geval is. En dan gaan kijken naar zaken die meer impact maken.

[laurens0619]

Eem mail oplossingen komt er vaak post delivery achter dat een bestand malicious was en wil deze dan wissen.

Als het bestand online staat dan is de kans groter dat het direct online geopend wordt en dus niet ergens in de pst/tmp van de client staat. Online wissen is eenvoudiger dan wissen op de client

[ Voor 13% gewijzigd door laurens0619 op 05-04-2023 19:46 ]

[mrmrmr]

CAPSLOCK2000 schreef op vrijdag 31 maart 2023 @ 13:27:

Conventionele wijsheid is dat het mailen van bestanden gevaarlijk is en dat het dus verstandig is om bepaalde bestandstypes te blokkeren. In plaats daarvan wordt aangeraden om het bestand te uploaden naar een of andere filesharing website en dan een link te sturen.

Ik geloof niet dat dit ooit een goede manier is geweest.

Dit wordt bijvoorbeeld aangeraden (zo niet afgedwongen) door Microsoft, bv op de pagina Blocked attachments in Outlook.

Microsoft adviseert een Microsoft oplossing.

Het probleem van sturen van links naar veilige fileshareshites (die van mijzelf) is dat Microsoft die link onderschept en zonder meer als onterecht als onveilig bestempeld, al voldoet de site aan alle security eisen, die vele malen beter zijn dan die van Microsoft zelf. Die links kunnen ontvangers dan niet openen is de claim.

Tegenwoordig upload ik (PDF) bestanden met AES256 wachtwoordbeveiliging. Als een organisatie prooi wordt van ransomware artiesten kunnen ze daar niets mee.

Het wachtwoord stuur ik via een ander transport. Daar wordt vaak vreemd van opgekeken en het gebeurt dat intern (lees: via Microsoft) het wachtwoord en het bestand alsnog via email wordt doorgestuurd. Tegen domheid en onachtzaamheid is geen kruid gewassen.

De veiligheid van mijn gegevens acht ik van hoger belang dan de gebrekkige beveiliging in een organisatie. Ik weet wel hoe ik bijvoorbeeld met persoonsgegevens moet omgaan, en de ontvangers weten of doen dat niet.

Steeds meer mensen lezen hun mail via webmail, in hun browser dus. Het idee dat een browser veiliger is doet er daarmee niet meer toe.

De browser is fundamenteel niet veiliger dan email.

Doordat moderne websites bol staan van javascript is het nagaan wat een website doet (en of er troep in zit) veel moeilijker dan de inhoud van een e-mail controleren.

Ja, en veel kwaadaardige scripts bestaan uit verborgen payloads die meerdere coderingslagen hebben.

Websites zijn dynamisch, je kan ze niet eenmalig keuren want ieder volgende bezoek kan de site helemaal naders zijn (in tegenstelling tot e-mail).

Email kan beter worden gecontroleerd door meer scanners dan "realtime" controle van/in browsers.

Het controleren van de afzender van een mail is makkelijker geworden door technieken als SPF en DKIM, PGP en SMIME

Ik heb nog nooit een PGP email ontvangen van iemand die geen ICT-er was. S/MIME idem. SPF en DKIM kunnen niet worden geblokkeerd vanwege false positives. Toch pleit ik ervoor om vooral ook DANE/CAA controle in te voeren en op lange termijn af te dwingen in email. Daarmee kan via certifcaten de beveiliging en vooral de exclusiviteit op een redelijk niveau worden gebracht.

Het is veel lastiger om te controleren wie de eigenaar/afzender is van een bestand op een grote filesharing site.

Vaak worden gevoelige gegevens verstuurd via schimmige bedrijven. Daartoe reken ik niet alleen de file sharing sites die populair zijn bij warez distributeurs maar ook die van Microsoft, Google en Apple en andere Amerikaanse bedrijven die niet kunnen voldoen aan Europese privacy wetgeving.

Sommige organisaties hebben een eigen file share server. Dat vind ik wel acceptabel indien wordt voldaan best practices: automatische verwijdering binnen korte tijd, versleutelde opslag, malwarescans zonder bestanddeling met derden (verdachte bestanden niet automatisch opsturen).

Iedereen heeft een virusscanner nodig om bestanden/sites te controleren die je met je webbrowser controleert.

Bijna iedereen. Je kunt best zonder virusscanner veilig internetten als je het goed inricht en weet wat je doet. De kans op zero days in browsers ligt aanmerkelijk lager dan 20 tot 10 jaar geleden.

Ook e-mails worden gecontroleerd en ik zie niet in waarom dat anders of minder veilig is.

Provders kunnen dat doen ja, de onderschepping aan clientzijde leidt vaak tot problemen en kan de privacy en security op andere manieren schaden. Het wordt vaak als mitm geimplementeerd. Daartegen heb ik een principieel en ook pragmatisch bezwaar.

Het is heel gebruikelijk geworden om bestanden te zippen of van extensie te veranderen om ze toch te mailen. Gebruikers kennen dat en zullen zo'n bestand zelf terughernoemen/unzippen. Deze vorm van bescherming (file extensies blokkeren) is dus maar heel beperkt.

Extensies blokkeren heeft nooit zin gehad. Altijd inhoudelijk blokkeren. Aan de andere kant is email niet waterdicht te maken als er aan de binnenkant iemand meewerkt. [methoden censuur]

Onze data staat steeds meer online in plaats van op onze eigen computer. Een webbrowser hacken is daarmee gevaarlijker aan het worden(?) dan een mailclient/pc hacken.

Ik zou zeggen dat websites gevaarlijker zijn geworden dan email. Bij verreweg de meeste sites is er wat betreft veiligheid van alles mis. Het begint al met het niet correct gebruiken van CSP en ook DANE en het gebrek aan security en privacy door gebruik van diensten van derden (denk aan Google analytics, Google fonts, cookiemelders, etc.). Security by design en privacy by design zijn de adagia.

Email is te beveiligen door HTML te versimpelen, offline te maken en scripts niet uit te voeren. Verreweg de meeste aanvallen hebben hulp nodig van de ontvanger. Die moet een executable direct of indirect uitvoeren. De dreiging van openen van emails en meteen besmet is nagenoeg niet bestaand bij het up to date brede publiek. Zero days zijn kostbaar en zeldzaam.

Er is ook nog een advies dat zegt dat je niet op links in je e-mail moet klikken. Dat botst regelrecht met het advies om links te mailen in plaats van attachments.

Dat is nooit een correct advies geweest. Het was voor beheerders makkelijk om dat aan gebruikers mede te delen. Websites zijn niet gevaarlijk tenzij je zelf een beveiligingsfout maakt. Onder "zelf" mag je ook verstaan de beheerder van de werkplek. Als jouw organisatie het doelwit is van "statelijke actoren" moet je je beveiliging daarop aanpassen zodat zero days niet effectief kunnen zijn. Dat betekent dat het vieze internet via een aparte terminal sessie moet lopen, bij voorkeur op een niet-Windows besturingssysteem. Daarmee weer je >90% van de aanvallen af. Dit wordt wel steeds moeilijker omdat managers denken dat SaaS de oplossing voor alles is en developers die alleen Chrome gebruiken dat intrinsiek onveilig is en geen privacy biedt. Internet rechtstreeks op de werkplek of werkomgeving maakt het wel erg makkelijk voor aanvallers.

Verder wil ik niet onbenoemd laten dat er nog steeds e-mail via onversleutelde verbindingen wordt gestuurd.

Emailservers dienen een geldig certifcaat te gebruiken en alleen een veilig protocol zoals TLS 1.2 en 1.3. SSL en TLS 1.0/1.1 moeten niet worden ondersteund. Daarnaast moet OCSP en DANE worden actief ondersteund (zowel client- als serverkant). Het is verstandig om mail te weigeren die niet TLS 1.2 (standaard met TLS 1.3 vergelijkbare suites) of 1.3 ondersteunen. Tenzij je werkt voor een sector die de maling heeft aan beveiliging, zoals de internationale transportsector of Chinese handel.

Is het nog steeds nodig om e-mail attachments grotendeels te blokkeren?

Naar mijn mening is het dat nooit geweest. Je mag wel executables blokkeren, ingepakt of niet. En (nu spreek ik mezelf tegen) versleutelde bestanden of bestanden zonder herkende structuur.

Verder kun je bestanden parsen en zien wat er in zit. Je kan bijvoorbeeld macro's slopen uit Office documenten. Of Javascript uit PDF bestanden. Dat is overigens ook het grote nadeel van malwarescanners. Die gebruiken parsers die an sich onveilig kunnen zijn. Vaak gaat het over oude code die ontstaan is voor het exploittijdperk dat circa 1999 begon op de desktop. Scanners ondersteunen grote aantallen bestandstypen en sommige bestandstypen zijn fout gedocumenteerd. Het Word doc format bijvoorbeeld bevat vele off-by-one's.

Het aanpassen van emails heeft belangrijke nadelen. Het kan kapotte emails herstellen. De kapotte emails komen door de scanner, Microsoft Exchange hersteld die en maakt de payload werkend, voorbij de scanner.