Thursday, January 31, 2002

 
Posted by Mike Tarrani 6:29 PM
One thought leads to another. In my 31 January entry that I posted at 3:51 AM in Notes from the Field I discussed LDAP, role-based access controls (RBAC) and software QA. The only apparent tie-in among the topics was the relationship between LDAP and RBAC. I'm going to step back onto the soapbox and discuss a real-life relationship among LDAP, RBAC and QA. The names have been changed to protect confidentiality.

Background

The company for which I was working had developed a security infrastructure that used directory services, policy servers and other components to achieve a single sign-on, enterprise-wide infrastructure that was independent of applications and platforms. On paper it looked viable. The first customer was one of the largest manufacturers in the world.

According to company lore the client's CIO bought into this design based on a one-hour presentation. With authority to proceed in hand a small team descended upon the client's site and commenced implementing this panacea.

Fast forward to a different client half-way around the world. We were not tasked with implementing the same solution, but were tasked with including a recommendation for a security infrastructure in a strategic plan. The plan was to be a 5-year roadmap for how the technical and process domains were to evolve. In went the untested and unproven security infrastructure that was still being implemented for the international manufacturer.

I'm going to jump back to the project for the international manufacturer: my involvement in that project was to bring the portions that touched UNIX systems into production. I was a consultant serving as a member of the client's production services team. I was working for a different company at the time and was an on-site consultant who was hired away by the company that developed the security infrastructure - what a tangled web we weave.

When I was assigned to the strategic planning project half-way around the world I was no longer directly involved in the first project. However, when I was involved I noted (in writing to the client) that there was no testing done on a system upon which the client was depending for security. Moreover, the entire infrastructure could be bypassed if there were no guidelines for integrating new systems into the infrastructure. Finally, nobody had taken the time to assure that access controls were provably correct; there was no mathematical analysis of the design, nor were there any test plans or cases with which to validate new applications being integrated into the environment.

Two glaring problems surfaced with respect to this unproven scheme:

1. The products upon which the architecture was built had flaws. One reported incident allowed a user to assume the more extensive rights of another user. This was swept under the carpet by a statement by the CEO of my new company that, "it's such a rare bug that it will not happen again." Product qualification and design testing would have caught that.
2. In the strategic plan that was drafted before I joined the other project, the recommendations were for products instead of standards. This goes against all that is sacred in IT strategic planning, which is supposed to be based on solutions and standards - not products.

Results

The following occurred:

1. The company at which I landed was thrown out of the international manufacturer, and the project handed to another consulting company. Ironically, it wasn't because of the flaws I cited above - it was because of poor project management and other reasons that are not germane. In defense of the company that lost the project, I'll say that the client was as much to blame for project management deficiencies, and certainly deserves a share of the blame for approving a project that was built on such a shaky and untested foundation.
2. Something different happened with the second client - they were quick to complain about the fact that products, not solutions and standards, were included in the strategic plan. They wanted alternatives as well as an in-depth strengths/weaknesses/opportunities/threats (SWOT) analysis performed on our initial recommendations and the alternatives. This was handled by rewriting the strategic plan, eliminating product recommendations and replacing them with standards.

Lessons Learned

1. Never buy into a solution, especially one as critical as an enterprise security infrastructure, without a copious amount of due diligence. Among the actions that the international manufacturer's CIO should have taken or caused to be taken are:
   • Investigated the company before buy-in - suffice to say that some probing reference checks may have raised red flags
   • staffed out to in-house experts (security, architecture and production services) an analysis of the proposed solution. Issues and factors, such as the use of Novell's NDS, would have elicited concerns (Novell products were on the forbidden list per standards and policies), and the production acceptance requirements would have been made known to all stakeholders - an omission that triggered schedule and cost overruns later in the project because they were not taken into account.
   • ensuring that products cited in the solution were investigated and there were provisions for a functional qualification test. An example of what happens when such steps are not taken is illustrated in a recent report about Microsoft Passport flaws (see also another horror story).
   • no business case. A decision was made based on a presentation without any business case to prove the value. In my opinion this debacle was created on the back of a cocktail napkin. I'm sure a PowerPoint presentation was also involved.
2. Formal proof of design for critical infrastructure components is essential. Enterprise-wide directory services depend on role-based access controls, which need to be designed and validated using set theory. To the best of my knowledge nobody on the client or vendor side had the skills or knowledge to undertake this.
3. If an important part of an architecture touches everything then test plans and cases need to be developed. If not specific plans and cases, a framework and templates that can be tailored are the bare minimums. Needless to say, this was not done.
4. In the case of the strategic plan, there are also lessons to be learned. Among them:
• Never base a strategy on a product - especially a long-range strategy. Products come and go, they evolve quickly, and are not a proper foundation. Standards, on the other hand, change slowly (if at all), and serve as a basis for a solid architecture.
• Extensive investigation is required, as is traceability. If you're doing strategic planning you need to:
  • explore alternatives
  • assess the strengths and weaknesses (as well as the opportunities and threats) of those alternatives
  • document how you arrived at your recommendations and why
  • trace back technical decisions to business requirements
  • cite references that support your projections (i.e., Meta Group, GartnerGroup, etc.)

Postscript added at 17:56 PST: See related article that reinforces what I wrote above.