The SOFT Insider Threat

I've written a lot about the insider threat and what it means to me. A while back, I spoke to IT Business Edge about my opinion that non-malicious insiders pose a greater risk of causing a breach than malicious insiders. Many in the industry still claim that insiders should not be a major cause for concern and that external threats should get the lion's share of attention.

It's fairly easy to see that malicious attacks cause immediate and expansive financial harm. But, the unintentional or at least non-malicious insider breaches, which I'll call the Soft Insider Threat, occurs far more often – perhaps hundreds of times every day.

Today, I read a story in NetworkWorld titled Inside a Data Leak Audit that illustrates my story.

The IT Director at a pharmaceutical firm facilitated a data leakage audit for his company. Before the audit, the firm believed they "were in good shape". They "had done internal and external audits" and "extensive penetration testing". They had intrusion detection and prevention solutions, laptop encryption, and employee training. What they found out is that "you can do all that and it's just not enough."

The audit, conducted by Networks Unlimited, revealed gaping holes, including:

• 700 leaks of critical information, such as Social Security numbers, pricing, financial information and other sensitive data in violation of the PCI-DSS standards.
• Over 4,000 incidents that ran counter to HIPAA and Defense Department Information Assurance Certification rules.
• More than 1,000 cases of unencrypted password dissemination, such as to access personal, Web-based e-mail accounts.

A few specific examples:

• Employees sent ZIP files and attachments of confidential documents in unencrypted emails.
• An employee attached a clinical study report in an unencrypted email to an outside vendor.
• An employee sent sensitive employee compensation data to an outside survey company inc. salary, bonuses, sales quota, stock options, granted share price and more.

This single audit conducted on one company revealed 11,000 potential leaks that not only went unreported as data breaches, but wouldn't have even been known about or identified as problematic if the audit wasn't going on at the time.

I call them soft breaches because they're not intended to be harmful and may not ever cause harm or get noticed. But if they happen 10,000 times over the course of two weeks, that's 260,000 security violations each year. And those are real breaches that may violate HIPAA or PCI-DSS, expose employee and customer information, violate business contracts, and otherwise cause potential for harm. It should be pretty apparent that if this happens 260,000 times each year, that's a pretty big attack surface.

As the author and auditor say in the article, don't leave security in the hands of end-users. Automate the important stuff and track activity on a regular basis to ensure that your attack-surface is in-line with your risk tolerance. Don't ignore the soft insider threat just because it gets overlooked. That's the exact reason why you need to address it.

Defining the Cloud

I just read another definition of Cloud Computing. It was a pretty good one, similar to what I submitted to the non-geek definition conversation. To save you the suspense and extra clicks, Andre Yee defined Cloud Computing as:

An on-demand delivery model for IT services or applications with the characteristics of multi-tenant hosting, elasticity (variable capacity) and utility based billing.

My version was:

Shared computing infrastructure over the web that distributes cost across participants and lowers the cost for each.

I actually like Yee's better than mine. I was focused more on the business purpose than actually describing what it is.

In thinking further, I think we should remove applications from the definition. Applications are delivered As a Service or On Demand. But it is infrastructure that is provided 'in the Cloud'. When we talk about Cloud Computing, we're talking about shared infrastructure (hardware, OS, security mechanisms, backup, etc.). I personally wouldn't use cloud terminology to describe what salesforce.com has made famous.

Salesforce isn't sharing infrastructure with other software providers. They're just including the infrastructure as part of the value they provide to customers. Their delivery mechanism internally looks a lot like what cloud computing providers offer, but they're offering it to their own customers.

Cloud Computing is a service for software or solution developers that can reduce cost by leveraging a shared infrastructure that is billed based on use. Those developers then offer their solution As A Service. But, they can also offer their solution As A Service without utilizing a Cloud infrastructure. They can, as Salesforce did, build their own infrastructure.

What do you think? Worthwhile distinction? Clear?

If the UI fails, the application fails

A blog posting by Luther Martin at Voltage reminded me of something I said a long time ago when I was developing Web applications:

If the UI fails, the application fails.

I probably wasn't the first or only person to have ever said that, but I think it rings true today and is especially applicable to information security practices.

Luther is specifically talking about cryptography and uses an analogy of mechanical clocks. If people had to understand how the clock worked in order to read the time, the clock would no doubt have failed to reach widespread adoption.

But, we have no trouble assuming that end users should understand that they need the HTTPS and should verify certificate authorities because obviously without proper SSL, the information they pass to their bank is exposed to snooping attacks and they are susceptible to phishing attacks. What?!? That statement contained five terms that most people off the street wouldn't even be able to define -- never mind understand well enough to use the technology properly to safeguard against relevant threats.

Security needs to be built-in. And the User Interface needs to be easy-to-use and simple to understand. Otherwise, as we've seen, the security mechanisms will fail.