I blogged a post back on July 20, about a federation agreement which I had been asked to sign as part of allowing MS employees access to one of our business partner extranets. That post, here, talked about how the federation agreement was really around risk management, etc… and that this agreement from our partner was based on our own agreement here at MS (which we’re in the process of getting changed).
Recently, I was (figuratively) smacked upside the head, by a different federation partner – one who has been doing various forms of SSO for a while – with their approach to this whole federation agreement nonsense. And let me tell ya, I kind of like it.
I would describe the approach that some of us (MS included) were taking previously, like this:
From high upon the mount, the federation commandments were handed down:
Thou Shall have passwords.
Thou shall have provisioning.
Thou shalt… blah blah blah…
Seriously? not very friendly…but as I described my other post – this is pretty much what it’s like.
Along comes this other partner, who we’ve been working with for quite a while, but instead of reaching down from their ivory tower with a list of commandments that we must meet, it was more like:
(buddy walks over, putting his arm around your shoulder)
“So hey, we’re in this together, but we still share some responsibility. So can you tell me just a little bit about your stuff so I can decide if I want to do this?”
In addition to some generic boilerplate legaleze that accompanies any type of agreement (THIS CONTRACT DOES NOT CONSTITUTE A WARRANTY, EITHER IMPLIED OR EXPLICIT, BLAH BLAH BARF). We received 4 doc’s from this partner. They were:
- FederationOverview.pdf – Yup, just like it says – a primer of general federation technologies. Answers to questions your partner might ask if this were all new to them.
- Federation Integration Guide.pdf – Details required specifically to set up the federation with them. Short, brief, but everything you needed to know if you already knew/had federation capabilities. This is very similar to the “onboarding package” we provide to our partners for onboarding with us.
- Federation Integration Questionnaire.doc – Form for providing company information, business and technical contacts, etc… This also contains the fields for including your signing certificate, URL/URI info, etc…
- Federated Identity Risk Value Assesssment.doc
This last one was the most interesting, because it mapped directly to the “Security Requirements” in the previous templates. Only, instead of being a list of requirements, it was a survey which looks like this – only with much better formatting that didn’t translate to the blogosphere – (names hanged to protect the guilty):
In the following section, please select Yes or No next to each question. For some questions, additional details are requested.
1. Does your company have written and formal security policies in place?
2. Does your organization have a Chief Security Officer or an equivalent position? If so, please provide their name and contact information.
3. Does your organization perform annual or periodic reviews of your security program and practices? This can include any security audits, SAS-type reports, and/or ISO certification?
4. Does your organization utilize an existing identity management system? If so, please describe its architecture, number of users, how extensively it has been deployed within your company, and how long it has been in production.
5. Has your company implemented a Federated Identity solution with other companies? If so, please describe that solution. Does your organization provide single sign-on with any third party product or service?
6. Does your organization have an incident response plan in the event of a suspected or confirmed identity management security breach? If so, how will that plan be integrated with <company> since such an event can impact our Federated Identity Agreement?
7. Please describe your user (employee) provisioning and de-provisioning process.
8. Are contractors or vendors within your organization going to be included in this Federated Identity arrangement? If so, please describe how they are provisioned and de-provisioned in your organization’s identity management system.
9. Does your identity management system handle ‘orphaned’ accounts? If so, what are the policies?
10. Are individuals (both employees and non-employees) provided with a unique, non-changing or static user ID or authentication credential?
11. If you are using unique, non-changing or static User IDs or authentication credentials in your system, are there rules employed to create them (e.g., randomly assigned numbers within a range, made up of the individual’s name or other personally identifiable information, created by the user?) If so, please describe how user IDs are generated.
12. Are there any attributes used for validating the user upon being provisioned with a company-wide authentication credential? Will the authentication credential be utilized in this Federated Identity Agreement?
13. Do you provide systems and resources to maintain and monitor authentication audit logs and transaction logs? If so, how long do you store them and can they be utilized for any forensics?
14. What methods and physical controls are in place to prevent unauthorized physical access to your company’s identity management system? Select all that apply.
[ ] Network servers in locked rooms
[ ] Physical access to servers limited by security identification (access cards, biometrics etc)
[ ] Video monitoring
[ ] Sign-in logs and procedures
[ ] Security badges or ID cards visible at all times in secure areas
[ ] Security guards
15. Which of the following areas are covered by your password management and application security policy?
[ ] No common password policy is in place
[ ] Use of static passwords
[ ] Are any User Accounts (ID’s) shared
[ ] Password length restrictions (min/max):
[ ] Password aging, # of days:
[ ] Password lockout, # of attempts:
[ ] Password reuse
[ ] Password content (alphanumeric requirements):
16. Which of the following best describes your method for authenticating and authorizing access to your systems and applications?
[ ] No common method is in place
[ ] Authorization/Authentication performed by supporting operating system
[ ] Single sign-on
[ ] Two-factor authentication for internal and confidential information
<since this was in a word doc, the formatting was much, much, much better than what translates via Live Writer – and I left out some sections which weren’t relevant, such as contact info, etc…>
Since I’ve mentioned the formatting thing twice now, it’s probably worthwhile to address the, “why not just edit and post the Word docs”? Because I’m not necessarily trying to poke your copy/paste nerves, but rather, I’m shooting for something a little bit deeper than that. I’m actually targeting the synapses responsible for thinking, understanding, and applying the general principle – and giving examples, so you can see/understand what other folks are doing.
I’m a big fan of this type of approach, it feels like this is much more inline with what the federation agreement is supposed to be about. More geared towards evaluating a partner against your risk tolerance, and making an informed decision on your own, rather than trying to beat some square peg into your round hole.
I suppose it’s also worthwhile to point out, that there is a lot of detail asked for here – that you may not necessarily feel comfortable giving to someone else (I actually deleted most of the lines which just said: Details: for easier reading). This may be true, in fact, I actually had the same thought when I first saw this. But then it dawned on me, that this service provider happens to be one who is providing financial and tax services for every MS employee. They already have a whole smack-ton of our confidential information to begin with!
Even still, when I filled out the form and sent it back, it was with limited information and in some cases, I didn’t fully answer all the questions. In my experience, these types of documents are used to start the conversations, not necessarily end them.