Success in Autonomy

Most companies are striving to reduce total costs for operations, support, development, etc., in order to increase profits. One might then ask: "Why do some large companies, with many interior lines of business, refuse to collaborate and share"?

The answer is very simple: One can attain Success if working in Autonomy.

There are many reasons why this is actually a good motto to live by:

1) If a particular line-of-business is dependant on another in order to deliver on a committment, that lob may fail to achieve their business objectives, such as a product launch, which may mean millions in missed-opportunity cost.

2) If a lob shares another lob's infrastructure, then if there's an outage, both may be incapactiated. Isolation of business disruption (aka Business Continuity Planning).

3) Lastly, most manager's bonuses are based on achieving goals; reliance on another may not get you your bonus.

Food for thought.

Vendors, be Honest

A colleague of mine recently e-mailed:

"What I've seen in the past is that COTS applications are selected based on (1) functionality fit with user requirements and (2) vendor's ability to come to terms with ... purchasing. Once those two things are satisfied, contracts get signed and the project moves forward."

This got me to thinking about the total cost for a new vendor product. Obviously, if the product is selected, money is committed. For some products, this could mean a high license fee. License fees are not the only element of committment. Integation costs, training for operations support, hardware, and ongoing hosting are all costs which need to be added. Based on researching the integration and deployment costs for the environments I've delivered, on average, for every $1 spent in licenseing, figure $2-4 additional cost before the solution is whole and in-production. This could mean alot of money in the end (e.g. if $150K of licenseing, then an additional $400K project to get it into production).

Much of the decision process for a product is based on the sales process, and statements by the vendor about the product's ability to meet the requirements. Therefore, "[it's] unacceptable for vendors to tout features during the sales call and then later say one shouldn't use those features", my colleague further wrote.

Honesty about the product and product quality is a huge issue with any large organization. Recent product quality issues have caused my client to begin considering a replacement. This will undoubtedly cause large costs for systems replacement and data migration, but my client feels it's worth it, given that they have provided the vendor opportunities to correct the problem, but it doesn't seem to have an effect.

Furthermore, honesty about a product is required else a company may not make their business committments. With regulatory requirements, product launches, emergence into new markets all weighing heavily on a company's bottom-line, if your product becomes part of the critical path to deliver, the lawsuit from fines, revenue-lost, or other lawsuits could be severe.

Morale of this blog: Vendors, be honest about the products you sell, and be honest about your committment to support them once they're sold. Else face a penalty which far exceeds the license and the deployment cost combined.

Why are my Directory costs so high?

In recent months I've been hammered by my client to get my costs down. "Why does it cost so much to run a Directory!?!?!" he said, and went on to threaten "The quote I got from [an India Application House] is 10% of what you're charging!!!".

Unfortunately, many application development houses don't take these conditions into consideration ... they're focused on programming, lines-of-code, and not the operational stability of something that underpins many applications. If you were to talk to them about databases, their comment is typically "well, that's handled by the database provider". That begs the question: "So then why do you think you can do it for 10% of their cost?" They thought that Directory was a black-box item which could just be installed and runs on it's own. I can assure you, this is NOT the case in the real-world.

However, my client's inquiries did make me double-think my cost-model. I called an industry-analyst earlier this year to get an idea of what an average FTE-per-Server ratio is for running Directory environments, their answer was 1:1. That seemed high to me. I further inquired "is that for a highly available directory environment, or just a single instance on a box". The answer was "the latter".

I ran numbers, and a 1:1 ratio would've caused me to go up in price, not down. Then I though about it ... "What do I do today to support my client's Directory?" and "What are my client's biggest complaints OUTSIDE of price?" I asked.

Directory servers are like Database servers ... they're middleware components that other applciations use. However, unlike databases, they're just now maturing as a major shared component in the environment. The costs to design and operate one must accomodate for constant change imposed by the applications who use them. Unbounded searches, new ACI's, Schema and DIT extensions all lead to continuous reviews, change controls, and thorough testing. When supporting a critical application, the Directory itself becomes critical, resulting in the need for high-availability designs, strict maintenance and change windows, and back-out plans. Furthermore, the tuning of the Directory can severely impact the responsiveness of the applications it supports. Unindexed searches can lead to long response times, causing more than one application to be affected. Throwing hardware at it doesn't help (e.g. who cares if it's a v880 if you've limited your instances to 2 simultaneous connections).

My client did have performance issues, stability issues, and I had been throwing bodies at it to solve this problem. This led me to think about the end-to-end support model, and I believe three items need to be considered:

1) Engineering the initial Directory solution based on requirements
2) Operatiions and Maintenance of the Directory enviornment,
3) On-Boarding Applications to the Directory environment

To gain Operational stability of your enviornment, you need to control the inputs and outputs. This means the initial design in the 1st step has to take a "assume deny" approach, prohibiting applications from utilizing the Directory unless explicitly authorized. It also has to accomodate for the service levels and expected volumes.

Operating the environment requires stringent monitoring and proactive maintenance, looking for trends and executing minor changes to further tune and optimize performance. Applications will not notice this singularly, only at the aggregate level w/in the directory will such trends be seen.

Quite often the3rd step, Application On-Boarding, is missed. Applications, once authorized to query the Directory, could still reak havoc unless they're programmed and tuned to "behave well". Often applciation developers don't give this a thought ... they'll short-cut their programming and testing by doing wild-card searches and parsing the resultant data themselves, vs. learning how to create well-formed queries to retrieve only the data they need. To prevent this, applications must run standardized tests, developed by the Directory team, to check for unindexed searches, wildcards, too-many-threads, etc. Only if the application passes would it be deployed.

Ok, so how does this relate to costing? Well, once you consider all the functions that need to be conducted, including designing, operating, maintenance, tuning, and application on-board testing, a ratio of 1:1 starts to seem reasonable. I explained this to my client, and they began to understand the periphery of work which surrounds the initial Directory design, which the [India Application House quoting at 10% my rate] hadn't even begun to comprehend.

In the end, I did come up with a repeatable cost-model (don't ask me to share the numbers), which allowed me to be more cost-competitive AND show value to my client by explaining (in more detail than I can put in this blog) why my numbers were right, and how it improves the quality and stability of their enviornment.

The moral of this blog: It's not always about the price, but about what you get for it.

Shibboleth: Great for Unions

One of the biggest concern of a low-seniority UAW-employee is backlash / ramifications for filing grievences, voting against striking, or otherwise not going-along with the "bretheren". Voting on union contracts is sometimes done by show-of-hands in large rooms. This certainly puts peer-pressure on a large majority. How does one overcome this scenario?

Enter Shibboleth. Utilizing Shibboleth technology and methodology, the UAW could be the Identity Provider and vouch for the member's identity, ensuring the member is trusted, yet providing the anonymity necessary for filing grievences or reporiting wrong-doing noticed on the job. Vice-versa, the auto-manufacturer could vouch for the same person back to the union for voting.

In summary, I foresee more applications of Shibboleth in many industries beyond schools and government, and encourage Internet2 to take this on a non-tech business road-show.

SALES: Who is your Target?

At EDS I'm very controversial. About 10 months ago, in front of the Security & Privacy Practices leadership, I declared that Identity Management is NOT a security initiative.

[Arms went up, voices raised, general mayhem.]

"I can do an entire IdM program without technology, and without any relevance to security" I further claimed ... and went on with this example:

"If I get, via a letter delivered via the postal service, updated information about an individual's employment status, and I trust the letter, and my job is Cellphone service management, then I'm going to take some action, such as deactivating the phone, and saving the company possibly thousands of dollars in cost."

They argued "isn't deactivating the phone a security item". Well, no, it's not. It's called ASSSET MANAGMENT, and is a business process.

All of IdM is about business process. Security, compliance, cost-savings, and user-experience are all residual benefits depending on what business process you're addressing. The main reason for IdM is to make an organization more efficient, and more accurate about their records. One drives down cost and improves user experience, the other avoids costly penalties from failed audits.

My main client, GM, recognized this fact and has intentionally distanced their IdM organization from the Security Office. Furthermore, they're aligning with the Business, not the IT organization. Jarrod Jasper illustrated this in his Burton Catalyst speech.

So then why are so many vendors and consulting firms still selling on security, regulatory compliance, and driving it from their security solutions group to the IT organization? Go talk directly to the business instead. Don't bring a SE, but a Finance guy instead. Your sales will do better because you've now sold the solution on IT's behalf.

Real People Theory

OK, so this next blog is a bit on the abstract, but related to a quote from Bob a couple years back:

"identity is people's perception of you".

-------------------------------------

The "REAL PEOPLE THEORY" was a concept that Mike Brown, Mike Maes, and I came up with back in college (during one of our late-night sessions in the "fishbowl"). In the past 15 years I've been trying to disprove it ... so far, no luck. The THEORY is very simple:

• Unless you've met someone through 2 independant sources, they're just a figment of your imagination.

So here's an example ...

Many of the people you work with are imaginary. One person (call her Sally) may introduce you to another (call him Joe), who you've already met (say, at the coffee machine). While Sally is still imaginary, Joe now becomes 'real'.

However, sequence is important. If you'd first met Joe through Sally, then saw him again at the cofee machine, it's not considered an independant source, and Joe remains 'imaginary'.

So, one might ask "did Sally have to be real for this to work". The answer is No, it's possible for two different real or imaginary people to independantly introduce you to a third, and the third becomes real without the others becoming real.

-----------------------------------

Before you ask, Yes, I took lots of Philosophy in college, but No, was not my major.

In DNS We Trust

If DNS is really the foundation of how the Internet runs, then shouldn't we focus on improving it's underlying security measures?

Most federation and identity technical specs make the assumption that the name-resolution was accurate (e.g. not spoofed). What if that's not true? What if DNS gets hacked?

Maybe it's time to update the DNS specifications to include a digital signature, or checksum, to ensure the integrity of the name/ip resolution. In comes DNSSEC ... the question now becomes: "when will it be in wide-spread enough deployment to be effective?"

passel ...

I finally got around to reading the Passel whitepaper. Thinking back on prior readings, others have proposed a third-party data-brokers which handle all communication and selective document handling between parties (I think there was even a "notary public" PKI architecture which did very much what passel proposes).

Furthermore, it seems to me that Passel, SAML, Liberty ... even PKI ... are based on the assumption that DNS is trusted. From the Passel whitepaper:

The pass MUST contain the following information:

• The fingerprint provided by the Agent in the request.
• The date of issue (which MUST NOT be in the future).
• The expiration date (which MUST be later than the date of issue).
• The secure URL at which the Signer's service description file is located.
• The value(s) requested by the Agent.
• The profiles which a Target can use to verify the counter-signed value(s).

The key here is "secure URL", which loosely means "trusted hostname as provided by my local DNS provider". Now, if I compromize the DNS, spoof the IP address, then I compromize the entire foundation of trust on which pass was established. Even signatures could be compromized if the asymmetric keys are both swapped.

I met with XNS.org about 3 years ago (before they became XDI/XRI) and they got it right: Identity has to be as foundational to the Internet infrastructure as DNS. I believe one of the reasons DNS works is how distributed and temporal it is ... if you get a "non-authoritative" answer, don't trust it and look somewhere else. Passel does have a distributed nature, but it's not the only one with that claim.

I'm going to have to seriously ponder this one more ...

certificate of trust

I am looking at a certificate of trust. If I give this certificate to any bank, they will not question it. It has been signed by a third-party, but they will not check this at all before accepting it and processing my request as a result of the presentation of this certificate.

What type of certificate is this? It's a certificate stating that there's a revocable trust for my estate, establishing my wife and I as trustees.

Although it's a photocopy, the bank will take the risk that the document is authentic until there's fraudulant activity. In that case, the courts will get involved, and ultimately some damages may or may not be rewarded.

We are trying to replicate this model in the digital world. The difference is this: you're not there in-person, with a photo-ID, to identify yourself to the receiving party. Safeguards must be installed for such validation.

One might ask: "Maybe one of the safeguards should be laws which can be invoked through the courts?"

My answer: "Take a look at spammers and phishers ... they're hard to find because the Internet was designed to be inherintly anonymous. Only recently was a case brought before a court. Do you really thing laws will help?"

Identity 2.0 needs to happen, if for nothing else, than to avoid the risk of reliance on the courts to restore peoples identities and thier lives.

curse of a realist

andy just pointed out that those of us with day-jobs don't have time to blog all the time ... curse of a realist ... have 3 in draft, but have been busy with my deliverables due this friday