Identity Management in 13 Easy Steps
by Ioana Justus
If you were asked to throw a few million dollars out the window, would you do it?
If yes, let me know where and when – I’ll happily wait outside with my catcher’s mitt. More likely, the quick answer to this question is a resounding “NO”. Few circumstances would lead someone to literally throw millions of dollars out the window, down the drain, etc. Not a million dollars, not in a million years.
What about companies that, effectively, waste millions of dollars trying to implement identity management?
The sad reality is that many organizations trying to implement identity management do just that – waste big money – on the wrong technology, or even on the right technology that sits idle because it can’t be used as designed. Worse, some organizations look to even more technology to “fix the shortcomings” of their selected product. The end result is the identity management version of Frankenstein’s monster.
If you peruse the latest identity management articles from your favorite research company, you’ll find the same discussions over and over: How do we justify the cost? Why do so many companies stop at “single sign-on”? Why do implementations take so long? Why do implementations get halted mid-effort? What’s the true benefit of identity management? What’s the ROI? You’ll also find the same tired answers – whether in printed form, or at one of the many IAM conferences across the country: IAM saves costs at the help desk. IAM can help with audit. IAM can reduce headcount in your access services department. Companies bite off more than they can chew, ROI takes too long, so they give up.
But what does it all mean?
Are we really doomed to these behemoth infrastructures that sit largely un-used, while we pay off consulting and software bills that often run into the millions (if not tens of millions)?
No, we’re not.
IAM is not a lost cause. It can lead to lower costs, easier audit processes, and a demonstrated postive return on investment (ROI). But it takes time – and discipline. As with many aspects of security, identity management is not about technology – it’s about people and process. The technologies are out there, and getting ever-more mature. But, IAM is NOT a Mac or an iPhone – you don’t just turn it on and it magically works. There is a lot of configuration and even custom development that needs to be done after you install your product suite of choice. Even before that, there is a TON of data cleanup, data modeling, and process design that needs to take place, and that is at the heart of this series:
Identity Management in 13 Easy Steps
Of course, the series title is a bit tongue-in-cheek. There’s nothing particularly easy about identity management. Then again, it’s not rocket science, either. It just takes a little thought and a lot of tedious effort – and did I mention discipline? The focus of this series is all on process and data. In fact, product selection is saved until the very last article. That’s right – if you can keep your instant-gratification urges at bay, I recommend that you don’t even bother buying anything until you’re ready to use it. Why spend all that money on a fancy technology if it’s going to sit there, idle, while you beat your head against the wall trying to clean up the data and processes that it needs to function?
An identity management implementation will only be as good as the data and processes feeding it, and that’s the problem many companies face today – most organizations buy a product and figure out after the fact that they have a ton of work to do to make it function. As a result, there is such a lag between the time of purchase and the time of ROI, most management teams lose patience and halt the effort. If you pave the way to implementation by first cleaning house, when you implement the technology its benefit will be seen quickly, which will encourage management to keep it going and try more.
There’s another critical aspect to this approach: gaining the needed experience to properly document requirements. Identity management is extremely complex. No one can just walk in and “get it” in one sitting. Even if the high-level concepts seem obvious, you have to live with the dirty details for a while to really understand the needs of your particular situation. The better that understanding, the better the requirements. The better the requirements, the better the product selection. Choose the right product, and you avoid tossing millions out the window.
Are you ready for this journey? If so, let’s get started. Here is the series I have planned – one article per month. This may not seem like much, but unless your implementation will have a very small user base, it will take longer than a month to execute most of these steps anyway. Of course, the series may change along the way – I’m already concerned about the volume of information I’m trying to fit into some of the articles. I may find as we go that a few of these topics will require multi-part articles. We’ll deal with that when it arises.
For now, here’s the intended schedule:
December 2009: Identity Management 101 – an overview of the different components of an IAM suite, to make sure we’re all on the same page and speaking the same language.
January 2010: Identifying Systems Integrations – not all systems will integrate (directly or indirectly) with IAM. Determine which ones will feed the priority list for the data cleanups and process work.
February 2010: Data Cleanup Part 1 – before your identity management system can work, it needs to be populated with all userIDs, and those IDs have to be clean. The first cleanup is focused on the primary IDs such as AD/LDAP and other key systems.
March 2010: Data Cleanup Part 2 – a key benefit of identity management is the ability to link userIDs in multiple formats from a variety of systems to the user’s primary record. The second cleanup focuses on identifying which IDs belong to which users in preparation for proper linking.
April 2010: Preparing for Password Self-Service – password self-service is a key cost savings of IAM, but it’s harder than you might think. This article will help you prepare your policies and your users for the technology to come.
May 2010: HR as a Source of Record – the HR system is a primary source of record for employees. It can also be one of the primary sources of errors and limitations for identity management. This article will explain the issues that most companies experience when interfacing with HR technologies (and departments).
June 2010: Role- and Rule-Basing – in order for auto-provisioning and -deprovisioning to work, the roles and rules need to be defined. This article will teach you how to avoid turning this effort into a rat’s nest.
July 2010: Role Hierarchies – workflows cannot be enabled without proper approval processes. But approvers aren’t always line managers. This article describes the various role hierarchies that should be established, and the synergies that can be achieved between identity management and other sources of record (e.g., financial systems).
August 2010: Workflows – workflows are the key to automating many processes. This article discusses the considerations in setting up workflows to ensure that they function effectively.
September 2010: Termination and Transfer Gotchas – terminations and transfers are key control activities that are of great interest to auditors. Getting this right in identity management will save everyone a lot of work. Getting it wrong can be disastrous. Learn the pitfalls in this article.
October 2010: Password Self-Service – whereas the April article deals with the foundational aspects of password self-service, this article deals more with the implementation aspects: how to select challenge questions that make sense, exposing PSS outside of the corporate network, etc.
November 2010: Effective Business Cases – now that your house is in order and you have almost a year’s experience with your organization’s circumstances, it’s time to build a business case to buy a product. This article explores a number of value-added functions of identity management that will intrigue your management and encourage them to allocate budget.
December 2010: Requirements and Product Selection – you’ve cleaned your data, defined your processes, and secured a budget. It’s finally time to pick a product. This article will help you document and prioritize detailed requirements based on a year’s experience in the trenches, so that you can make the best product decision possible.
Firefox Patch Tuesday
by Carl Anctil
Background:
A few months ago, Microsoft released (and silently installed through Windows Update) a .NET Framework Assistant add-on for the Firefox web browser. Microsoft installed this add-on to Firefox without warning the user that the add-on would be installed as part of the .NET Framework 3.5 Service Pack 1. Security professionals, bloggers, users in general all over the Internet were in an uproar over Microsoft’s activities. Propel forward a few months, and Mozilla proactively disables two Microsoft-installed add-ons; one of them is the infamous .NET FA add-on. Following some discussions with Microsoft, Mozilla later selected to unblock the .NET FA, but continued to block the .NET Windows Presentation Foundation add-on.
Situation:
The browser is rapidly becoming the “new” OS, and add-ons are the “new” applications. This is the new computer model. The momentum is moving toward SaaS, IaaS, PaaS and other cloud computing acronyms. The impact this is having is such that our browsers are acting more and more like Operating Systems.
If we look back and remember how networking has evolved over the years, we will notice a pattern. Many years ago, networking emerged from thin clients, then it advanced to thick clients and now we are going back to thin clients. The browser is the new thin client. It’s essentially the new OS. It isn’t a coincidence that Google’s new OS is called Chrome OS. Or is it? Can anyone say: “Firefox patch Tuesday”? I think we may have witnessed the first Firefox patch push.
When Mozilla decided to proactively block two Microsoft add-ons, the result of this action was effectively the same as patching a vulnerability (automatic updates). The reason these two distinct actions are similar is because the results are the same; they both prevent, fix, or block a vulnerability from an exploit. The block imposed by Mozilla impacted every instance of Firefox automatically, without user interaction.
What’s even more disturbing with this model is its ability to completely bypass many perimeter defences. This cloaking behaviour is a huge blow for the security of our networks. It’s giving a transporter to our adversaries to infiltrate our networks. Once inside our browsers, this enemy fundamentally becomes a virtual insider on our networks. It turns our users into allies and uses tactics that are very effective and easy to deploy: Tricks like social engineering, spear phishing, SPAM and emails with various types of specially-crafted attachments, etc.
We must protect and educate our greatest asset, which is coincidentally also our weakest link: The user. Vulnerabilities such as XSS, XSF, drive-by downloads, etc. are almost always triggered by trusted, authenticated and authorized users on the network.
Conclusion:
I just touched on this subject, but I believe a general awareness strategy will have to play an important role in the future. The bad guys will keep winning as long as they are the only ones reaching out to our users. We must positively reach out to users or they will keep getting tricked into doing things against us (and themselves).
Embracing Manjoo’s Madness
by Dennis Kuntz
There was a little bit of a buzz recently regarding an article on Slate called, “Unchain the Office Computers! Why corporate IT should let us browse any way we want”. It’s basically a litany of complaints about how the IT department, “that class of interoffice Brahmans,” decides “ridiculously and capriciously, how people should work”. Very clearly it wasn’t going to win a bunch of fans from the Security Twits lurking around on Twitter’s infosec community.
The author’s rants run the gamut from legitimate beefs to notions that would make the most incompetent infosec employee cough up a hairball. He also seems to be completely unaware of the myriad legal, HR, and compliance bogeymen that serve as drivers of so many security policy restrictions. All of that coupled that with what seems to be a disrespect (or at the very least a disregard) for the skills, responsibilities, and intentions of your friendly IT worker would certainly make him a difficult customer.Who wants to deal with that?
A lot of the reactions to the author’s opinion were expected and understandable. If I recall correctly, “clueless” and “dangerous” were at least two of the words used to describe it. I don’t necessarily disagree with this either. The point of this post is more about what comes next: Do we, as those “interoffice Brahmans” simply thumb our noses at a very rash and simplistic view of the whys and hows of security-and-policy-minded restrictions, and tell the author to get the USB key that he found in the parking lot out of his PC and get back to work so that we can get back to saving the world from the l33t h4×0rs whilst doing the Dew? While not everyone would take that tack, let me suggest a different approach anyway.
The author, Farhad Manjoo, represents reality. He’s a real person who uses real technology in the real world. And he’s frustrated. He also represents a pretty wide view. In a Cisco-commissioned study on leakage prevention (get the papers here, and a decent summary here), it was discovered that:
“The majority of employees in eight of the 10 countries surveyed indicated that they believed their company’s security policy was unfair or impeded their ability to do their job. Employees with more access to collaborative Web 2.0 applications and social networking sites, video and mobile devices, expressed that they increasingly used these technologies in the workplace but were frustrated with rigid or outdated IT security policies that limited their use. “
With that, we need to accept that he and people like him are our customers. Rather than slough off Mr. Manjoo’s opinion as just being one of the uneducated masses, I contend that it’s our job to listen to his opinion and address it appropriately:
- If the reasons for a particular policy are draconian or reactionary, they should at least be reviewed, if not changed/updated or eliminated.
- If the reasons are justified (“justified” here does not mean “because we, the Brahmans, said so”; it means a very real, pragmatic justification for which there is not a reasonable alternative in order to protect the data/assets), then they need at the very least to be explained. Education and continued relationship- and awareness-building would be even better.
- If the policies really cause them to not be able to do their jobs (which does indeed happen), our job – and one of the aspects of it that makes what we do so cool, challenging, and fun – is to think creatively of how to allow them to do their jobs while keeping the data/assets safe.
I say let’s bump things up a notch: Make it a point to seek our your own personal Mr. Manjoos, embrace them, and convert them. Difficult customers, once converted, can become some of your greatest supporters. They might even spring for the Dew.
Case of the Found USB Thumb Drive
by James Costello
It was a dark and stormy…
All right, it was a sunny morning in April when the first event to inspire this article occurred. I was walking back to my car after dropping off my daughter at school. As I walked around to the driver side I noticed a battered USB thumb drive sitting on the ground behind one of my tires
My first thought was “Oh, great. I dropped mine and it got run over.” I quickly realized that dropping it and running over it was nearly impossible and that it was not even one of the brands that I use. So I had four options:
1. Leave it were it was
2. Take it back into the school and leave it in the front office
3. Take it with me and try to determine the owner so that I could return it to them.
4. Throw it away.
The first option didn’t sit well with me; the next person to come along might do something malicious with it. The second option only works when the office is open (which it wasn’t, as my daughter was attending day camp during spring break). That left me with options 3 and 4. I decided to combine 3 and 4 into option 5:
5. Take the drive with me and throw it away later.
Fast forward in time three weeks…
I am once again in the parking lot of my daughter’s school staring at a smashed USB thumb drive of the same brand as the prior unit. Repeat thought process above. I was a bit suspicious and a bit curious. Two similar drives in the same parking lot. Was someone just very unlucky and lost two drives? Were there possibly two such unlucky individuals? Was someone trying to use the USB keys as a means to penetrate the school district system?
I decided that I would take a look at the new drive when I got home that evening, but I was going to take precautions. Plugging it into my computer could expose me to viruses, malware, and pictures of an inappropriate nature. What could I do to protect myself and my computers while looking at this drive?
1. Boot of BackTrack CD and mount the drive and look at it there
Advantage – lives in memory, low chance of infecting my hard drive
Drawback – this might not be a recommendation for others
2. Launch a VM on my computer and connect to the drive
Advantage – no need to reboot my hardware, I already have the VMs in place
Drawback – there could be malware that breaks through that VM software and infects my host system.
3. Boot a separate system that I do not mind rebuilding
Advantage – system can be rebuilt if there is malware on the drive
Drawback – not everyone has spare systems lying around to do this.
I chose to use an older Toshiba laptop to look at the drive because it runs Linux (lower chance of infection) and it has a USB 1.0 connector on it (older, slower, and not likely to run U3). Fortunately (or unfortunately) this drive was too damaged to operate, so it followed its predecessor into the electronic recycling bin.
Then I got to thinking. What if that drive was mine? Do I keep any data on a USB drive that, if I lost, could be used to steal my identity or perform credit card fraud? Would I want someone else going through it to find out if it was mine?
So what can you do to protect yourself losing your thumb drive and your data?
Keep physical control of your thumb drive, by keeping it on a key chain, on a lanyard around your neck, or at home. Protect the data on the drive, via encryption (there is a mobile version of TrueCrypt that works on USB drives). Alternately, don’t put anything on your drive you wouldn’t share with your neighbor, such as tax data, your social security number, your date of birth, or your mother’s maiden name. Don’t share your drive with anyone else, and don’t carry your data with you. You can leave it at home and email any information you need to yourself using your company’s mail system (not from your home account, but through webmail) if that is allowed by your company. Make sure you find out what your employer’s policy is for USB drives before you bring them in.
This “case “ was fairly interesting for me, and I hope you found it interesting, dear reader. The next time you come across a thumb drive laying around, think of this story and my thoughts. Now go out there and be safe.
Your Data Self
by Aaron Titus
Georges-Pierre Seurat was a 19th century French painter credited with starting Neo-impressionism and developing a painting technique called “pointillism.” His famous painting, La Parade, contains the detail on the right: A complicated series of blue, orange, pink, red, black, and yellow dots that together create a man’s profile.
This detail is the single best visualization of your “Data Self” I have seen. Your Data Self is a collection of your credit report, Facebook page, Google results, Bank account numbers, archived e-mails, and an endless parade of other data. Like pointillism techniques, which juxtapose contrasting dots to create vibrant masses of shaded tones, each piece of personal information is a single dot. Perhaps one is your address, your middle name, your pet’s name, or your favorite color. Maybe some represent your family, and others represent your friends or religious beliefs. Some represent your travels, magazine subscriptions, and purchase habits. Still others are intimate thoughts.
Taken individually or in small groups, they do not mean much- they may even seem to contrast or contradict one another. But all together they form your profile, or Data Self: A pretty good, but not 100% accurate representation of who you are. And this profile is exactly what data brokers, government actors, and marketers (among others) are trying to determine.
We leave trails of dots as we interact with others, especially online. As Gregory Conti, a computer science professor at the United States Military Academy at West Point, explained, “Free Web services aren’t free. We pay for them with micropayments of personal information.”
Since your Data Self is a digital alter-ego, with the power to enter contracts, grant access to your financial assets, have surgery, or commit crimes, you should actively shape and control access to your Data Self.
Hat tip: Daniel Solove
When Did My Personal Information Become Your Property?
A colleague recently asked me, “When did my personal information become someone’s property?” It’s a question with a vital answer, because if my personal information belongs to someone else, then they can do whatever they want with it. If data is property, then they can buy, sell, license, or give away my identity without my consent. This puts me at risk, because I must rely on the good will of a third party to keep my identity secure.
But if personal information really were property, then I should be able to permanently sell, or “alienate,” it. But unfortunately, I can’t sell personal information like a car. If I sell my car and the new owner paints it purple or runs it into a tree, it’s not my problem. But we all know that if I sell my personal information and the new owner “crashes” my identity, I suffer. Unlike all forms of property, personal information is inherently inalienable. Unless you enter the witness protection program, you’re stuck with your identity no matter how many times you sell it, and no matter how many times it is crashed.
Data is Property
Data behaves like property because 1. Data has value, like property. 2. Data is fungible, like property, and 3. Data is alienable, like property. For most types of information (ie, trade secrets, copyrightable or patentable information, etc) Intellectual Property law treats data like property with no problems, because trade secrets and patents are valuable, fungible, and alienable.
However, the analogy between data and property breaks down when we get to personal information, primarily because personal information is NOT alienable. Consequently, Intellectual Property law does not generally treat personal information as property.1 Most personal information, such as names, addresses, phone numbers, and social security numbers are facts. Facts are not copyrightable.2 You can’t patent personal information,3 and it certainly isn’t a trade secret.4 In short, nobody “owns” my name, including myself. And if someone could “own” my name, it would most logically be my parents, since they created it. But my mom can’t copyright my date of birth, and the government can’t patent my social security number. My phone number is not an AT&T trade secret, nor is it mine.
Personal information is valuable and fungible. Entire multi-billion dollar industries thrive on the sale and exchange of personal information. United States election law requires candidates disclose the value of all in-kind campaign donations, including databases of potential voters.5 Other federal and state statutes, such as the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act, require corporations to account for the fair market value of assets, which may include customer data. And personal information is extremely fungible, as information in databases can be shared, sold, licensed, stolen, or lost with remarkable efficiency.6
Because personal information is valuable and fungible, it is often treated like property. Tort law implies that some forms of privacy come from a trademark-like ownership of one’s name and likeness.7 Even breach notification laws seem to assert that companies which collect personal information “own” it.8
But that isn’t the whole story. Unlike every other form of property, personal information is not alienable, (such as bank account numbers, credit scores, social security numbers, or police reports) even if a third party creates it. And unfortunately, you don’t have any constitutional right of privacy when you give your personal data to a third party.9
Because personal information is not alienable, it is sufficiently different from traditional “property” that IP law does not provide a helpful framework for managing it.
Self is Data
In the Information Age, you are not much more than “an electronic collage of bits of information, a digital person composed in the collective computer networks of the world.”10 In other words, a person may now be defined as just a few pieces of data. This data is your Data Self. Your Data Self is a collection of your credit report, facebook page, Google results, Bank account numbers, archived e-mails, and an endless parade of other data. Your Data Self is a digital alter-ego, with its own personality, dispositions, fallacies and mortality. Your Data Self also has the power to enter contracts, grant access to your financial assets, have surgery, commit crimes, or be kidnapped.
When your Data Self belongs to someone else, it can be forced to act against your will. If someone makes your Data Self sign a contract, you are bound by it. If your Data Self is convicted of a crime, you can go to jail. If someone forces your Data Self to take out a loan, you must repay it. If your Data Self has an operation, you may no longer qualify for medical insurance. If your Data Self is abused, stolen, sold, manipulated, or forced to act against its will, you suffer the consequences. In this sense, “Identity Theft” might be more descriptively defined as “Digital Kidnapping.” Identity Theft is when someone pretends to be you by “kidnapping” your Data Self, doing something bad, and you get blamed.
Self is Property
In my view, this is a startling development. As long as my Data Self is a third party’s possession, then they can also treat me like property. In other words, if Self is Data and Data is Property, then Self is Property. The now popular crime of Identity Theft is the most visible consequence of this trend. In fact, “Identity Theft” epitomizes the problem with treating personal information as property: The very term recognizes that you have an alter-ego digital “identity” or Data Self. It also acknowledges that your Data Self can be stolen and abused, like property.
Fortunately the 13th Amendment ended human trafficking, and human muscle, once required for agriculture and labor, does not command the same economic premium in a post-industrial society. Instead, a person’s economic value now lies in his access to financial assets and credit. Our Data Selves are easy to coerce, and people are now worth more in bytes than in flesh and blood. As long as Data Selves are digital property, new crimes similar to identity theft will continue to arise, and our society runs the sinister risk of a new form of human trafficking: A type of Digital Slavery, where third parties can own, abuse, and force Data Selves to act against their will.
Facing the possibility of this new class of crimes, the law should neither permit personal information to be treated as property, nor can we afford to go down that path.
Aaron Titus is the Privacy Director for the Liberty Coalition, runs National ID Watch, and welcomes feedback.
Footnotes
1. 19 NO. 7 Intell. Prop. & Tech. L.J. 5, 8
2. Feist Publications, Inc. v. Rural Telephone Service, 499 U.S. 340, 363-64, 111 S.Ct. 1282, 1297 (1991) (Holding that an alphabetized collection of personal facts in a phone book is not copyrightable because 1. Facts are not copyrightable, and 2. The phone book lacks minimally creative selection, coordination, and arrangement. “As a statutory matter, 17 U.S.C. § 101 does not afford protection from copying to a collection of facts that are selected, coordinated, and arranged in a way that utterly lacks originality.”)
3. 35 U.S.C.A. §§ 101-102.
4. Facts in a database may qualify for trade secret protection under state law, but only if the information meets stringent requirements, and remains secret. 19 NO. 7 Intell. Prop. & Tech. L.J. 5, 8.
5. 2 U.S.C.A § 431(8)(a).
6. Identity Theft Resource Center, Press Release – 2007 Breach List; Privacy Rights Clearinghouse, A Chronology of Data Breaches.
7. “Tort” law is common- or judge-made law that allows people to sue others for doing bad things. For example, the tort of Appropriation of Name or Likeness is when someone uses a person’s name or picture for financial gain: Rest. 2d Torts § 652C cmt a. (1977) (The Tort of Appropriation of Likeness gives the individual “exclusive use of his own identity, in so far as it is represented by his name or likeness, and in so far as the use may be of benefit to him or to others. Although the protection of his personal feelings against mental distress is an important factor leading to a recognition of the rule, the right created by it is in the nature of a property right, for the exercise of which an exclusive license may be given to a third person, which will entitle the licensee to maintain an action to protect it.”);
8. See, e.g. Cal. Civ. Code § 1798.81.5(a).
9. United States v. Miller, 425 U.S. 435, 443-44 (1976) (Holding that bank records have no fourth amendment protection, and are subject to government subpoena with no infringement of an individual’s rights).
10. Solove, Daniel J., The Digital Person. New York University Press, New York. 2004. p. 2
Engage with Michael
-
Journey Into the Breach
