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.

Updates, NetVision, Oracle, etc

I haven't been blogging much this month. I was probably more active on Twitter when I had small contributions. ...and I blogged at the NetVision blog. Some of it was specific to what we do, but there are also some useful Tech Tips like posts on Active Directory Last Logoff and Last Logon - Attribute Confusion.

--

I've also not yet weighed in on Oracle-Sun. In a letter, Oracle's President (Charles Philips) says they're planning to:

Engineer and deliver an integrated system—applications to disk—where all the pieces fit and work together so customers do not have to do it themselves. Customers benefit as their systems integration costs go down while system performance, reliability, and security go up.

That makes sense from a business perspective. The key Sun technologies that were clearly interesting to Oracle are hardware, Java, and Solaris. And a hidden dark desire perhaps to mold MySQL as a non-enterprise solution so that there's no competition with Oracle's flagship product line. ...maybe that's just a bonus.

My personal opinion is that Identity Management had little or nothing to do with the purchase. In fact, it's probably considered a headache to the acquisition team. Clearly, it gives Oracle the number 1 spot in terms of IAM market share. And arguably the best suite of IAM products on the market. But, I don't know what that will mean to Oracle in their quest for world domination.

I was part of a very talented IAM team that got absorbed into a multi-billion dollar organization for which IAM was not a priority. And the team quickly disintegrated. I don't think that will happen at Oracle, but the IAM product teams will need to show management a strong revenue number to get the attention they'll need to integrate the Sun and Oracle suites properly.

Deborah Volk at Identigral wrote a nice post on the two product lines. I haven't used either enough to speak intelligently on which product might win the starting position. And Ash Motiwala captured one of my first thoughts. People always chose Sun because they were the big guy. The product wouldn't 'go away'. Well, there goes that theory. To quote Andre Durand from the NetworkWorld article:

This is yet one more reason companies should consider standards-based, loosely coupled approaches.

Perhaps the most intriguing aspect of this acquisition for the IAM world is the combination of all of those bright engineering minds in one room. The Sun Directory team, the OID team, the OVD team can join together and help shape the future of directory services while the Oracle Access Manager and OpenSSO teams can do the same for their piece of the puzzle. ...assuming of course that big-company bureaucracy doesn't get in the way.

[UPDATE: link to Felix Gaehtgens' Oracle-Sun product line comparison]

--

Speaking of innovation, one last thing before I close - NetVision announced a Series B round of funding today. The goal is to enable the innovation that we started with the industry's first managed service for directory and file system audit and monitoring. Be sure to keep your ear to the ground as we make another innovation announcement in the weeks to come.

On Multi-factor Authentication

Luther Martin of Voltage Security posted a very interesting post on the future of multi-factor authentication. In it, he challenged commonly held beliefs on the subject. Specifically, he writes:

It’s often claimed that multi-factor authentication is inherently more secure than single-factor authentication, but if you look at the history of this claim,it actually came from a vendor that wanted to make their multi-factor authentication product sound better than competitors' products.

(I'm not sure if these are his thoughts or if he's saying that was the consensus at a recent X9 meeting.)

Martin goes on to suggest that using two authentication mechanisms of the same factor may be as secure as using two factors and lays out scheme A & B to discuss.

So here's my thoughts:

Wouldn't scheme A be more secure because you can't brute force it? Isn't that the whole point of having the second factor? All passwords can be brute-forced given enough time. Having the second factor removes that threat.

Of course, you could implement a strong password plus a kill switch after 10 bad tries, but that still relies on the user to implement safe password storage. And I generally think it's better to remove any responsibility from the end-user (especially if there's a convenience trade off).

Requiring users to carry/remember two username-password combinations for every system doesn't seem practical. Security will fail if users try to subvert it for the sake of convenience. And they will.

Usability needs to be a key consideration. A token/pin combination is a secure and easy-to-use way to beat the threat of brute-force attacks and poor password management. ...as is having a certificate installed on a particular PC and other second factor solutions.

Courion Blog

If you work in the IAM space, you should already know who Courion is – being one of the top password management and provisioning vendors for the past decade and now having morphed into a full Access Assurance offering with role management and compliance solutions.

Well, in case you haven't seen it, Courion now has a blog. And so far, there's a lot of good content being written there. It appears to be a nice combination of industry analysis, business-value, and technical insight that remains on-topic. ...thought you might enjoy the pointer.

ADAM Pass Through Authentication to AD

A few years ago, I wrote a post that referenced ADAM passthrough authentication to Active Directory without providing much info. Since then, people searching on that topic have found themselves on my blog (probably hoping for more information). So, I thought I'd cover it in more detail.

Disclaimer:
I haven't actually done this in a few years, so my information may be out of date, but I'm sure someone will speak up if I'm wrong. ...they always do ;) I will assume you know what ADAM is, why you'd use it, where to get it, and how to install & configure it.

Why:
A few quick scenarios where pass through authentication is useful:

1. You want to put a portion of your Active Directory users into the DMZ for authentication by publicly-facing applications, but you don't want to expose an AD DC in the DMZ. In this scenario, the app can leverage a DMZ'ed ADAM for authentication. ADAM will still need to make a request to a DC, so AD is partially exposed, but in a more controlled way.
2. You want to leverage AD credentials for application authentication, but the app wants to store information about users that is not currently in AD and you don't want to extend the schema. You could stand up an ADAM instance, extend its schema however you want, enable passthrough authentication, and point the app to ADAM instead of AD.
3. You have an app that is used by people that have an AD account AND people that don't. And your app only accepts a single authentication store.

Here's what you need to know about using ADAM for pass through authentication to AD:

• The ADAM installation process gives you the ability to import the schema for UserProxy objects from a file called ms-userproxy.ldf – you'll need to import that object to enable the passthrough functionality. You can do it after the install if you need to.
• For an account to perform a passthrough authentication (aka a bind redirection) from ADAM, the account must be configured as a UserProxy object. A standard user account can not authenticate through to Active Directory.
• The UserProxy object has an attribute called ObjectSid, which is critical to this functionality. For passthrough authentication to work, the account's ObjectSid must be populated with the SID of the associated Active Directory user account (this will actually work with any security principal object).
• When a UserProxy account attempts to bind to the ADAM instance, ADAM recognizes the account as a proxy and forwards the authentication request to Active Directory.
• Passthrough authentication only works for accounts that live in the forest to which the ADAM server is joined (or to a trusted domain or forest). So, that's how ADAM knows where to send the request.
• Passthrough authentication only works with simple binds. So, the password is being passed to ADAM in clear text. You'll want to be aware of that and use SSL as appropriate.

That's pretty much all you need to know to get passthrough authentication working. As I recall, it's that simple.

Comments/Corrections:
PLEASE leave a comment if you're here because you want to do this for a reason I haven't mentioned above or if you have additional information. Am I wrong? Did I leave anything out?

More Information:
Microsoft refers to this as Bind Redirection for ADAM Proxy Objects. So, that's the terminology you'll want to use to find more information.

IAM as a Service - 20% of the Market

Today, Gartner identified their Identity and Access Management predictions for 2009 and beyond. First on the list is:

By 2011, hosted IAM and IAM as a service will account for 20 per cent of IAM revenue.

I've discussed managed services for Identity Management in previous posts. I think it's a natural progression. Identity and Access Management is an extremely complicated technology-set. Any given IT shop's ability to maintain the right skills to support an IAM environment is probably more costly (in effort and dollars) than outsourcing that function to specialists. And this certainly appears to be the beginning of an Era of Cost where cost has moved up the list of decision influencers.

I'm honestly a bit surprised and impressed to see Gartner come out on this one. I tend to think of them as a bit more conservative – making predictions that follow a trend that has already begun. Has this trend started to take shape or is Gartner a bit agressive on this one?