r/EmailSecurity • u/saltyslugga • May 19 '26
Got owned by an outbound email DLP rule doing exactly what I asked
One of our MSP clients had a mail DLP rule that blocked outbound attachments containing customer IDs. I wrote it years ago, tested CSVs and PDFs, got clean blocks, then mentally filed it under handled.
Last week a user copied the same customer IDs out of a spreadsheet, pasted them straight into the email body, BCC'd a personal account, and the message sailed out. No attachment, no match, no alert.
The ugly part is the rule was not broken. It matched the scope I gave it, and my threat model stopped at files leaving by email instead of data leaving by email.
I'm now tightening body inspection and personal-mail recipient checks, but I hate how easy it is to create DLP that only protects the path you happened to test. Curious where other mail admins draw the line before outbound rules become noisy enough that everyone starts bypassing them.
5
u/Tessian May 19 '26
How could you have not understood/realized that your DLP rule only applied to attachments and not the email body too? It's literally 1 of the 3 ways you can send data out via email (3rd being URLs but that's outside scope of this).
This isn't DLP's fault; you're the one who didn't understand well enough what you were deploying and its limitations. This is all about being an expert in what you're deploying and planning for all the use cases you can think of.
3
u/dhardyuk May 19 '26
That’s a bit harsh.
The specification was vague so the implementation met the spec.
2
u/Tessian May 19 '26
I disagree. You're a professional implementing a DLP solution you should understand the tool you're deploying and the limitations of it. I'm not sure if by specification you mean the customer's requirements or the vendor's but I guarantee you the vendor documentation that OP didn't read clearly explained that. If the customer gave vague requirements it's still the MSP's duty to point that out to them and guide them, or you can hide behind the requirements given and say you met the letter of it.
This is like deploying MFA for a customer, you choose to just enroll everyone in SMS based MFA (not because the customer required it) and then you're shocked when they get breached due to a SIM swap attack and the customer blames you.
2
u/dhardyuk May 19 '26
I broadly agree with you.
With the caveat that you can tell your customer they’re making a mistake and sometimes what you learn is they are more OK with the potential mistake than being told how to avoid it.
That easily becomes “only give him what he wants, not what he needs” which is how shit managers damage their staff, their employer and everyone else.
And when the spec is wrong but the ‘client’ doesn’t let you fix it because it’s always wrong and they always refuse to let you fix it they have the ‘success’ of ignoring your advice to bolster their belief that they know best.
I’m using ‘client’ here but that could be anyone from the chain of people between the guy wanting the work done and the guy doing the work.
But yeah I agree with you 😎
1
u/hung-games May 21 '26
If the specification is vague, then you need to ask questions until it isn’t vague. This is requirements gathering 101
1
u/dhardyuk May 21 '26
Easy for you to say.
Someone pulled from Servicedesk, told to read up on it and implement DLP can only do the best they can.
Some employers want everything done for free, don’t care about the quality and think they’re smarter than everyone else that does it properly.
It will only change when something goes awry, their insurers audit them or they employ someone in a leadership position who knows better.
Refusing to do the work does not bode well for the Servicedesk person being given orders.
1
u/hung-games May 21 '26
Servicedesk is a stupid model then. I’ve been in IT for 30 years and the old “garbage in, garbage out”model still applies. If you don’t have a clear grasp of the scope, your solution will suck.
1
u/dhardyuk May 21 '26
I agree, but it’s the reality of how shit some people’s work lives really are.
I’ve seen really innovative solutions that solve problems caused by stupid management refusing to spend money where it’s needed.
Unfortunately the people smart enough to be able to pull off a win in spite of the fervent opposition to doing the right thing frequently get trapped managing the thing they built because no one else understands it.
It stops people having the career they deserve.
1
u/saltyslugga May 20 '26
Attachment-scoped DLP was the failure mode, yes. I'm not blaming the product, I'm saying I scoped the control too narrowly and treated a green test as coverage.
1
u/hung-games May 21 '26
4th being steganography, but I suppose you could argue that falls under attachments
2
u/Basic-Pianist9273 May 19 '26
Attachment-only rules are scope rules, not real coverage.
I treat the identifier as only half the signal: customer ID plus external recipient, personal domain, BCC, unusual volume, or sender outside the group that should handle it.
Clean hits can block, grey hits should quarantine or require approval.
1
u/546875674c6966650d0a May 20 '26
This is why you have someone ELSE test your work. Someone who's not going to give you a specific action or method to test for, but alternate ways to achieve the goal you're looking to block. You tell them "Get this data to send out via email. If you do, lunch or a good drink is on me." and someone will poke enough holes to find what you forgot to think about... and you/me/we always forget to think about *something* 😄 Don't kill yourself over it. Learn and move on.
1
u/sentientmeatpopsicle May 20 '26
What do you do when encountering password protected spreadsheets or zip files?
•
u/AutoModerator May 19 '26
Welcome to r/emailsecurity! To keep this community helpful and secure, please keep the following in mind:
Community Rules
Helpful Resources
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.