Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is an interesting perspective.

Just as a counter argument, one of the things we tried to do at a previous employer was data exfiltration protection. This meant using outbound proxies from our networks to reach pre-approved urls and we don't want to mitm the TLS connections. This leaves a bit of a problem, because we don't want to whitelist all of s3, the defeats the purpose, so we had to mandate using the bucket.s3 uri style, which is a bit of a pain for clients that use the direct s3 link style, but then we could whitelist buckets we control.

I don't want to say this use case is more important, but I can see the merits of standardizing on the subdomain style, and that this might be a common ask of amazon.



Exfiltration protection is pointless. It's a great way to waste money and annoy your employees.


Within hours of setting up DLP, I had someone complaining I had broken their workflow. That workflow apparently involved emailing credit card numbers to an external personal mailbox "for security".

It was allowed to go on simply because noone knew about it. Could a skilled attacker spread a card card number across three lines and get past the system? Absolutely. Is exfiltration protection pointless? Absolutely not. Once you scale a certain number of users, you'll find someone somewhere that completely ignores training (which they did have) and decides they don't see the problem with something like this. And you won't know about it until you put a suitable system in.


This proves my point perfectly.

Instead of investing in i.proved tools and productivity for your workers so they dont have to do stupid shit you dont want them to do, you instead made it harder for everyone to do their job.

I'm not saying your business is going to crash and burn. I'm saying you will never be as successful as you could have been. You're literally wasting resources, leaving needs unfulfilled, and giving up ground to your competitors.


Wasting resources by preventing people from sending CC# in clear text to a personal email? That person is lucky they didn’t get fired for doing it


This is not a helpful comment. Could you provide some examples of why it's a waste of money?


Not the commenter, but I think the point is that there are simply too many ways to bypass protections. If you want someone to be able to view data, it is impossible to prevent them from exfiltrating it. In many ways it is similar to the analog hole problem with DRM.

You can make it harder to do on accident, or to prevent someone from doing it for convenience (e.g. someone copying data to an insecure location to have easier access to do their job), but you can't stop a malicious actor from getting the data.

They could tunnel over DNS, they could use a camera phone and record the data on the screen, etc. The possibilities are endless.

https://en.wikipedia.org/wiki/Analog_hole


> You can make it harder to do on accident

That's a major point of exfiltration prevention, both because accidents are a real problem and because reducing the opportunity for accidents makes it easier to establish that intentional exfiltration is intentional, which makes the ability to impose serious consequences for it greater (especially against privilege insiders with key contractual benefits that can only be taken away for cause.)

Technical safeguards aren't standalone, they integrate with social safeguards.


>> You can make it harder to do on accident >That's a major point of exfiltration prevention

But that’s not how it is advertised. Usually they claim is to catch hackers and mal intending employees.


Advertising is 100% bullshit, both in this space and elsewhere. I'm not sure why even well-paid people in positions of corporate power don't seem to get it. It's similar to Gell-Mann amnesia.


> You can make it harder to do on accident, or to prevent someone from doing it for convenience

Why are you discounting these as valuable use cases?

In my experience, they're far more common than the determinedly-malicious actor. And they're far, FAR more common than the malicious actor who also (a) knows that the exfil monitor is there, and (b) has the technical prowess to circumvent it. (The analog hole is only _trivially_ usable for certain kinds of data.)

(I am continually frustrated by the number of people who claim that protection is worthless if it's potentially circumventable. In most situations, covering 90% of attacks is still worthwhile.)


I agree. Locking my front door is trivially circumventable. It is pretty easy to pick up a rock and break a window. Or use a heavy instrument to break down the door. Or heck, a car could just go crashing through the wall. But that lock is a pretty good deterrent from casual abuse. It requires crossing a psychological barrier into the explicitly illegal and malicious realm.


That's a sensible analogy on the surface, but the difference is that having to lock the door doesn't

- end up forcing you to lock it from the inside, and then crawl out the window

- have your friend who is visiting request a door-opening-token 24hr in advance through a JIRA ticket

- cause the power to go out once it's locked, also for security reasons

- force you to replace the keys with 'special' plastic ones from a new third-party vendor

- leave you stranded outside for a few hours because the door-opening system is having an outage

Those are the kind of trade-offs that will be made, not simply the act of locking the door.


It's also the reason why people mail sensitive data to their private mailboxes and that no matter how hard some companies try, they can't make their employees stop using Excel as their primary work tool.

'arcbyte over at https://news.ycombinator.com/item?id=19827012 does have a point - a lot of potential exfil risk is caused by companies doing their best to make it as difficult as possible for their employees to do their jobs.


> I am continually frustrated by the number of people who claim that protection is worthless if it's potentially circumventable. In most situations, covering 90% of attacks is still worthwhile

People are saying that because it's misguided and potentially harmful.

Doing so is security theater, where the solution is scoped down to something incomplete but easier, and then everyone walks away happy they solved 90% of the smaller problem they chose to attempt.

Particularly with things like data exfiltration, this is potentially harmful because then you've organizationally blinded yourself.

Nobody wants to poke holes in their own solution, and so they stop looking.

But, hey, we're catching the odd employee accidentally sharing confidential documents via OneDrive.

Fast forward a year, and an entire DB gets transferred out via an unknown vector, nobody finds out about it for a couple months, and it's all "Oh! How did this happen? We had monitoring in place."

Go big, or run the risk of putting blinders on yourself.


The way I'm reading this, your attitude seems to be "if you can't stop targeted nation state actions you might as well not bother with network security and just run unencrypted wifi everywhere."

Network security is a balancing act between prevention, detection, needed user and network capabilities and cost. If I have unlimited money or no limitations on hindering network usage I can make a 100% secure network - it's not even that expensive, just unplug it all.


>covering 90% of attacks

It doesn't cover most attacks. That's why it's so misleading. It mainly just protection against incompetent people from accidentally sending out data.


Which is what like 80% of data leaks?


> there are simply too many ways to bypass protections

This is not a good general principle, since it can be easily applied in contexts that (I would predict) many same individuals would vehemently disagree with. For example:

- Personal privacy is pointless, there are simply too many ways for governments/corporations/fellow citizens to find things out about you

- Strong taxation enforcement by governments is pointless, there are simply too many avenues for legal tax avoidance and illegal tax evasion

- Nuclear arms control is pointless, the knowledge of how to make a bomb and enrich uranium is widely available (I mean, if NK could pull it off, how hard could it be?)

Maybe data exfiltration prevention isn't a good policy, but I think you need a more nuanced argument than 'there are ways around it'.


All these things work statistically, preventing a certain part of incidents.

They are not a guarantee that an incident cannot happen, though. They can only lower the rate at which incidents (privacy violations, tax evasion, nuclear proliferation) occur.

Same with exfiltration.


I read a great paper talking about this problem once, which made the point that the only actual measure of data security is the bandwidth of possible side-channels vs useful size of the data.


Do you happen to have any pointers about this? I would be very interested.


The parent was probably talking about this paper: https://csyhua.github.io/csyhua/hua-ipdps2018.pdf

Here are a few more (somewhat) related to this topic:

1.Joe Grand, “Advanced Hardware Hacking Techniques”, Defcon 12 http://www.grandideastudio.com/files/security/hardware/advan...

2.Josh Jaffe, “Differential Power Analysis”, Summer School on Cryptographic Hardware http://www.dice.ucl.ac.be/crypto/ecrypt-scard/jaffe.pdfhttp:...

3.S. Mangard, E. Oswald, T. Popp, “Power Analysis Attacks -Revealing the Secrets of Smartcards” http://www.dpabook.org/

4.Dan J. Bernstein, ''Cache-timing attacks on AES'', http://cr.yp.to/papers.html#cachetiming, 2005.

5.D. Brumley, D. Boneh, “Remote Timing Attacks are Practical” http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

6.P. Kocher, "Design and Validation Strategies for Obtaining Assurance in Countermeasures to Power Analysis and Related Attacks", NIST Physical Security Testing Workshop -Honolulu, Sept. 26, 2005 http://csrc.nist.gov/cryptval/physec/papers/physecpaper09.pd...

7.E. Oswald, K. Schramm, “An Efficient Masking Scheme for AES Software Implementations” www.iaik.tugraz.at/research/sca-lab/publications/pdf/Oswald2006AnEfficientMasking.pdf

8.Cryptography Research, Inc. Patents and Licensing http://www.cryptography.com/technology/dpa/licensing.html


Thank you very much for the material!


It's hard to prevent data exfiltration by an attacker with physical access to your premises, but it's much easier to prevent exfiltration (especially of large quantities of data) by compromised devices.


When there is a will, there is a way.


Any output device is an output device. A VGA interface. An HDMI interface. A Scroll lock keyboard light. A hard drive interface. A speaker. All you need to do is send the signal down one wire and you could tap into that wire and copy all the data to another system.

Copying files from one folder into another could do the job.


> ... A scroll lock keyboard light ...

Oh, this was a fascinating read! Thanks for encouraging my perusal.

http://staff.ustc.edu.cn/~zhangwm/Paper/2018_10.pdf


I brought it up because I had heard that the original iPODs ROM was extracted using the "click" sound and a microphone. I can't find any reference to it now...

There is also research about using modem lights (even in the background of a room) to figure out what people are doing on their dialup internet connection. Those RX and TX LEDs are actually blinking at your data transmission rate.



Generalising further, signal, channel, reciever.


But that isn't really a counter argument.. if you provide the ability to use both formats, your use case would still work (only provide access to the custom subdomain you control).


you're correct, it's just my experience with this is that certain libraries expected the url format we couldn't accept to be working, and didn't provide an alternative. So having more flexibility in the api can work against you at times is all.


since your employer is willing to invest in this, wouldn't a custom proxy solve your problem? just whitelist the s3 buckets you care about, and have people access s3 through the proxy.


This is based on using a http proxy, it's just the proxy whitelists the domains to connect towards. As for a proxy that can mitm tls connections, I'm not a big fan of this approach, as you ned to add a cert into the trust store of all the machines, which if compromised tends to be a bad day across the board.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: