Entries tagged with “insider threat”.

Just published a blog entry on my McAfee official blog. It talks about some of the trends of database security as we see them from the global McAfee Threat Report.

Just today I reviewed Verizon’s Intellectual Property Theft and it has a large section about databases, privileged users and compromised assets.

The one figure that caught my eye is this:

Compromised assets by percent of breaches involving Intellectual Property theft

As another year comes to a close, it’s time for both new year’s resolutions as well as predictions.

On the resolutions front, I hope to be much more active on my blog next year.  As we grow as a company, I seem to have less time for my musings, as I spend more time with customers and those we hope will become customers.  Overall, it’s a good problem to have…

As far as predictions go, this is always dangerous ground.  A year from now, someone will undoubtedly come back and point out that I really missed some major new trend, or called one that never came to be.  But, these are simply best guesses based on what I’m seeing out there, and I’d be happy to hear from those who have additional trends of their own. You can also read all about it here and here.

Hackers are getting better tools

This one will increase the frequency of attacks, based on several factors:

  • Automation will let good hackers move faster
  • Less skilled hackers will now be able to use more sophisticated attacks
  • Lesser known sites will see more “random” attacks as the tools look for vulnerabilities instead of the hackers targeting specific companies and finding a way in

More attacks will be based on outsiders turned insider

As the perimeter defenses become better, most companies have continued to neglect the risk of the privileged insider.  So, the easy money may go to alternative approaches to getting insider access.  Bribery and even extortion come to mind, but so does getting hired as a consultant or even an employee, mainly to get at the data.

I also put drive-by malware attacks in this category, as the unsuspecting user simply browsing a site lets malware in that attacks from the inside.

Organizations will focus on minimizing surface area of attack

The less content you have, the easier it is to lock it down.  Just as the e-Discovery era brought about email retention policies, we’re beginning to see people deleting sensitive records as soon as they are no longer needed, reducing the information at risk.  At the same time, tools like tokenization will limit the number of databases with actual information to just one, while apps only store pointers.  By securing the one live repository (I’d recommend Sentrigo for this of course!), you’re now protected.

Databases finally make it to the cloud

There’s been much noise about the cloud, but so far I haven’t seen many customers putting business critical apps, with sensitive data, in the cloud.  One reason has certainly been concern about data security (and compliance).  With solutions like Hedgehog, you can deploy a small sensor that gets installed whenever and wherever the cloud provider puts your database, and it is just as secure as in your own datacenter.  And you can monitor the admins at the provider as well.  As companies get comfortable with these technologies, critical databases will move to the cloud.

Compliance will remain a “bare minimum” effort

Not so much a new trend, but I expect in the continuing difficult economy, we will still see most companies investing the least amount possible to comply with regulations, rather than taking an approach of what they consider best practices to secure data.  Thus, we’ll still see breaches of “compliant” companies, and as a result there will be pressure on auditors to enforce more strictly, and pressure on regulators to update standards to fill commonly exploited gaps.  To stay on top of this, flexibility will be required.

So, here they are. I’d love to hear your thoughts…

While it’s not headline news yet (and may never achieve such lofty status), a recent database breach at UWF was exposed and later reported in local news. What exactly happened and how many records were compromised is, as usual in such cases, unknown.

This made me think: We hear of breaches at universities all too frequently. Privacy Rights Clearinghouse, a website that documents data breaches, lists over 140 breaches in universities since January 2005. That’s more than one per week on average. Ouch.

Why is that?

The crucial factor here is that universities have very large populations of “insiders”. Students are like employees: They are authorized users. They have logins and passwords. They are also young and rebellious, and many are tech savvy – e.g., computer science students, to state the painfully obvious. Some are “hackers”, looking to prove they can hack, or influenced by some anarchist/Marxist/New Age book they browsed in the library, and others may be more traditionally motivated by money, criminal intent or a deep desire to change their grades…

This is also a transient population, and very hard to control. Every 3-4 years the population changes almost completely. Unlike employees, they do not stay long enough to develop any kind of loyalty, plus of course the don’t get paid – quite to the contrary, they’re the ones paying.

What about the data itself? Naturally grades are very important to students, but they are of little value to anyone else. Other student data is a lot more interesting, including Social Security numbers, bank account details and other personally identifiable information – the bread and butter of identity thieves. At least gone are the days when SSNs were used as student numbers – although many of those still lurk in alumni databases around the US, which highlights another point: Although the population is transient, the data is not. It stays. A large-ish university will have hundreds of thousands of former student records. Quite the honeypot.

Universities mostly lack the IT resources that Fortune 500 companies have, but the challenge they face in securing their data is no less daunting. I think that one simple, non-technical solution would be not to collect unnecessary data in the first place, and if it must be collected for current students, dispose of it once the student graduates. As an alumnus, why would I possibly need my alma mater to retain my Social Security number?

Technically there are many things the universities can do, but I don’t want to already sound tedious on my second post (hint: If you don’t monitor database activity, you won’t know if the DB was breached, when, how, by whom and how badly – but enough of the hard sell)

What better way to start a blog about database security than to discuss what is possibly the biggest data breach ever?

It now seems that several banks are suing TJX over claimed losses of tens of millions of dollars – so negligence in data protection carries a cash penalty, not just nebulous damage to reputation. Gross negligence, in fact – this is not some one-off lapse in judgment such as a laptop with sensitive information forgotten on a bus, or a CD lost in the post.

The details recently published about the ongoing investigation provide insight into what possibly happened:

  1. The breach lasted 17 months: For 17 months someone (or more than one person) was systematically stealing data. I can only infer from this that security measures and procedures at TJX were grossly inadequate. It also means the breach was not accidental – it may have been opportunistic at first, but certainly malicious after that. More likely it was malicious from the start.
  2. Insider(s) were involved: It seems that some encrypted credit card data was decrypted using keys, which only an insider with privileged access would have. Whether such an insider was knowingly complicit or duped into divulging such information is unknown, but it shows us all what the sophisticated criminals already know – why bother sweating and hacking your way through firewalls and IDS when it’s so much simpler to use an insider?
  3. Utter lack of visibility: Most astonishing of all, more than 50 experts TJX put on the case have reached no conclusions. Besides not knowing how many thieves were involved, TJX isn’t sure whether there was one continuing intrusion or multiple separate break-ins, according to a March 28 regulatory filing.”
    In other words, the thieves either did a great job of covering their tracks (and they certainly had ample time to do that!), or worse, they didn’t have to do it because their actions were invisible to begin with…

It is clear that even a rudimentary audit could have prevented the breach from going undiscovered for so long. It is also evident that encryption alone wasn’t enough to protect the data, and that perimeter defenses such as firewalls are useless against inside jobs like this one.

But ultimately, the entire thing could have been prevented with real-time monitoring and intrusion prevention at the database level.