Approximately 80% of breaches are detected initially by a third party. Law enforcement, credit card companies, grey hat hackers, researchers like Brian Krebs.
It turns out breach detection is difficult. You can often determine that a system has been compromised, but being able to know that data has been lost is tricky. Given that most data compromises happen in minutes or hours, and take weeks or months to detect gives the bad guys an extreme upper hand.
One mechanism to help detect attackers traversing an environment are honeypot systems. Designed as both an early warning system and a capability to observe attacker behaviour in a safe environment, honeypots are rarely used because of their complexity (deployment, maintenance, etc). I’ve heard a number of smaller shops working to make this process easier through tools like virtualization and even virtual networks but it remains beyond the reach of most mid-sized organizations.
Another strategy I’m a fan of is ‘honey data’. The idea behind honey data is the creation of fake records which when accessed are an indication of compromise because no real user exists which would legitimately use that data. Examples can include fake login and system accounts, fake entries in database tables which when triggered show database dumps, and also legitimate credit cards created and stored in data tables only for the use of monitoring of credit card system compromise.
To use a horrible, horrible analogy from the recent US election - you’re putting a few poisoned skittles into your data set so that when the attackers go feasting, you can detect their activity.
The nice thing about honey data is when used properly it doesn’t need to add significant cost or expense, and provides a form of passive post-breach monitoring. And it helps the organization reduce the reliance on third parties being the first to notice your data showing up in the wild.