Blog post

More On Internal Data Loss Incidents

By Anton Chuvakin | December 31, 2012 | 3 Comments


"If a tree falls in a forest and no one is around to hear it, does it make a sound?” – If a piece of sensitive data is exposed to the intranet/LAN, is that a security incident?

Here are some versions of an answer I’ve heard (all fictionalized, of course):

  • “No, what on Earth are you talking about? We share everything inside the firewall.”
  • “No – since we would never know that it happened anyway.”
  • “Yeah, kind of– but it is low-priority incident, the one we get to … whenever we get to it”
  • “It depends on the data, some data seen outside its intended secure enclave immediately triggers an incident.”
  • “Yes, of course -  with 50,000 employees you cannot have any concept of a perimeter.”
  • “Yes, because our internal is really external – due to a large number of partner, customer, vendor, etc personnel on our network.”

However, the situation is much worse than that. I am this close to thinking that today at a large company with expansive and effectively uncontrolled network access (wireless, VPN, BYOD, etc), an internal breach is going to become an external breach before  you can say “DBIRSmile 

Here is why: a lot of the organizations open up all sorts of internal resources to all sorts of outsiders and then poorly govern access to said resources. A recent research piece on SharePoint contained this shocking number:  “nearly a third of these internal-facing SharePoint sites are now being opened up to people outside of the enterprise, such as partners and customers for external collaboration.” The authors further note, in a style reminiscent of a winning The Understatement of The Year contest entry,  “This changes the overall risk profile of SharePoint.”

In this scenario, an internal exposure magically becomes a data breach. In light of this, some organizations undertook massive (=covering hundreds of thousands of internal file repositories and millions of files) efforts to discover, corral and attribute (to data owners) sensitive data and then institute a blend of processes and ongoing technical monitoring (via DLP) for internal exposures, in addition to explicit exfiltration and “loss.”

Finally, here is a great example (discovered here) of an internal incident leading to formal breach disclosure:


(full notification is at

So, here is to change in the New Year: accept an idea that an internal sensitive data exposure may, in fact, be a security incident, even before the attackers get to this data and steal it!

Related posts:

The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.

Comments are closed


  • Ray says:

    Yeah, “fictionalized”. Let’s go with that. 🙂

  • Oliver says:

    Yes it is a security incident, which we follow up as soon as we detect them.
    As we are a IT Service Provider, we want to be sure that our data is protected in the same way and same policies are applied as with our customer data. If you’re not dealing properly with your internal data, how do you want to earn the trust of your customers that you do it right.

  • Oliver, thanks for the comment. Happy to hear about your approach! Sadly, there are always rumors of service providers who don’t disclose internal and cross-customer breaches in the fear of losing customers