There was an excellent article at Dark Reading the other day about data leaks focusing on insider threats. It did all the right things by pointing out “insiders have access to critical company information, and there are dozens of ways for them to steal it” and “these attacks can have significant impact” even though “insider threats represent only a fraction of all attacks–just 4%, according to Verizon’s 2012 Data Breach Investigations Report.” The article goes on to discuss how you can use gateways, DLP for at rest and in flight data, behavioral anomaly detection, and a few other technologies in a “layered approach using security controls at the network, host, and human levels.” I agree with every word.
Yet, there is one aspect of the controls that somehow escapes mention – letting a potentially powerful ally in this fight off the hook from any action. There is not one mention of proactive controls inside the applications and platforms that can be placed there by IAM. A great deal of insider access is inappropriate. Either it’s been accrued over time or granted as part of a lazy “make them look like that other person” approach to managing entitlements. And app-dev teams build their own version of security into each and every little application they pump out. They repeat mistakes, build silos, and fail to consume common data or correctly reflect corporate policies. If these problems with entitlement management and policy enforcement could be fixed at the application level, the threats any insider could pose would be proactively reduced by cutting off access to data they might try to steal in the first place. It’s even possible to design a system where the behavioral anomaly detection systems could be consulted before even handing data over to a user when some thresholds are breached during a transaction – in essence, catching the potential thief red handed.
Why do they get let off the hook? Because it’s easier to build walls, post guards, and gather intelligence than it is to climb right inside of the applications and business processes to fix the root causes. It’s easier to move the levers you have direct control over in IT rather than sit with the business and have the value conversation to make them change things in the business. It’s cheaper now to do the perimeter changes, regardless of the payoff – or costs – later. Again, this is not to indict the content of the article. It was absolutely correct about how people can and very likely will choose to address these threats. But I think every knows there are other ways that don’t get discussed as much because they are harder. In his XKCD comic entitled “The General Problem,” Randall Munroe says it best: “I find that when someone’s taking time to do something right in the present, they’re a perfectionist with no ability to prioritize, whereas when someone took time to do something right in the past, they’re a master artisan of great foresight.” I think what we need right now are some master artisans who are willing to take the heat today for better security tomorrow.
As the new season of conferences kicks into gear, I start to have thoughts too big to fit into tweets again. I once again had the pleasure of making it to London for the EMEA Gartner IAM Summit. There was a big crowd this year, and the best part, as it always is, was the conversations in hallways and at bars surrounding the official agenda. It’s always good to get together with lots of like minded folks and talk shop.
On stage, the conversations were intense as always. @IdentityWoman took the stage and educated a very curious audience about what identity can mean in this brave new mobile world. And there was an interesting case made that “people will figure out that authentication is a vestigial organ” by @bobblakley. But the comment that caught my imagination most of all was by author and raconteur Nick Harkaway, aka @Harkaway.
He links IP (Intellectual Property for clarity since there are a few “IP” thingys floating around now) and privacy in a way that never occurred to me before. @Harkaway says “both [are] a sense of ownership about data you create even after you’ve put it out into the world.” @IdentityWoman spoke at length about how our phones leave trails of data we want to control for privacy and perhaps profit reasons, and @bobblakley even proposed how to use that sort of data for authentication. At the core of both of those ideas is a sense of ownership. If it’s “the data is mine and I want to keep it private” or “the data is mine and I want the right to sell it”, it’s all about starting from the data being something that belongs to you.
I typically react with skepticism to IP but with very open arms to privacy. So to suddenly have them linked in this way was quite a dissonance. But what difference is it to say that I write this work of fiction and expect it to be mine even after it’s complete or I create this mass of geo-data by moving around with my phone and expect it to be mine even after I’m in bed at night? “But it’s the carriers responsibility to actually generate and maintain that data!” OK. But if I write my work using Google Docs does that alter my IP rights? Does it matter perhaps that the novel is about something other than me? Does it matter that geo-data is not creative? (Of course, some geo-data is creative)
I don’t have all, or perhaps any, answers here. But I thought this notion was worthy of fleshing out and further sharing. What do you think? Are IP and privacy in some way intimately linked?
I swear this is not just a hit grab. I know that’s what I think every time I see someone write about Apple. But the other day I was clearing off files from the family computer where we store all the music and videos and such because the disk space is getting tight. I’ve been holding off upgrading or getting more storage thinking that iCloud, Amazon Cloud Drive, or even the rumored gDrive may save me the trouble. So the research began. Most of it focused on features that are tangent to IAM. But Apple’s proposed “iTunes Match” got me thinking about how they would work out the kinks from an access standpoint in many use cases. If you don’t feel like reading about it, the sketch of what it will be is you have iTunes run a “match” on all the music you have you did *not* get from Apple and it will then allow you to have access to the copies Apple already has of those tracks on their servers at their high quality bit rate via iCould instead of having to upload them.
All the string matching levels of h3ll this old perl hacker thought of immediately aside, it became clear that they were going to use the existence of the file in your library as a token to access a copy of the same song in theirs. Now, my intent is to use this as a backup as well as a convenience. So maybe I’m not their prime focus. But a number of access questions became clear to me. What happens if I lose the local copy of a matched song? If I had it at one time does that establish a token or set some attribute on their end that ensures I can get it again? Since they have likely got a higher quality copy, do I have to pay them a difference? I had to do that with all the older songs I got from iTunes for the MP3 DRM free versions, why not this? Of course, if the lost local copy means that I can no longer have access to the iCloud copy, then this cannot act as a backup. So that would kill it for me.
But these problems have bigger weight for Apple than users not choosing them for backup features. There is a legal elephant in the room. How can Apple be sure they are not getting the music industry to grant access to high quality, completely legit copies of tracks in exchange for the presence of tracks that were illegally downloaded? In an industry supported by people paying for software, I’m always shocked at how lonely I am when I say my entire music collection is legal – or, at least, as legal as it is to rip songs from CDs for about 40% of the bulk of it. It’s one thing for a cloud provider to say “here’s a disk, upload what you like. And over here in this legal clean room is a music player that could, if you want, play music that may be on your drive.” But Apple is drawing a direct connection between having a track and granting permissions to a completely different track. Then pile on a use case where some joker who has the worst collection of quadruple compressed tracks downloaded from Napster when he was 12 and pours coffee on his hard drive the day after iTunes Match gave him access to 256 Kbps version of all his favorite tunes.
If this were a corporate client I was talking to, I’d be talking about the right workflow and access certification to jump these hurdles. Can you picture the iTunes dialog box telling you that your music request is being approved? That would be very popular with end users…
I sat down with a very smart group of folks and they were saying how they think SSO is very, very hard. If your world is all Active Directory (AD), it’s easy. But that is true in a tiny percent of the world. Everywhere there is some odd ball application and in most places there are just as many applications not using AD as there are using it (even if they buy Quest solutions, sadly). The cloud, something everyone is forced to mention in every tech blog post, also complicates this. How do you do SSO when the identities aren’t under your control? Or, reverse that, how do you get SSO from your cloud vendor when your on premise applications aren’t under their control? But every time I have the SSO conversation at length with people the conclusion is always the same. If all you have are applications from the last 10 years and some cloud stuff, there are approaches, including Quest’s, that can fully solve that problem. You can integrate into your commodity AD authentication, put up SSO portals, or use widely adopted standards like SAML – or all of the above in a clever combination. Even thick client GUI applications can be tamed with enterprise SSO (ESSO) solutions at the desktop. The things that always end up falling through all the cracks are older applications. Things that are often the crown jewels of the business. Applications that are so old because they are so critical that no one can touch them without huge impact to the business. But the older technologies resist almost every attempt to bring them under control. Even ESSO, which is the catch all for so many other laggards, can’t tame many of the odd green screens, complex multi field authentications, or other odd things that some of these applications demand at the login event. When I’ve spoken to our SSO customers, they always seem happy with 70-80% adoption on their SSO projects. They know they will never get that last group until the applications change. But there doesn’t seem to be any compelling event for those applications to be changed. So SSO continues to seem hard, but we all know that’s not exactly true.