IBM Dropping Tivoli Brand from IAM Suite

I just read this story on Network World about IBM's plans to make Q1 Labs' Security Information and Event Management (SIEM) product, QRadar SIEM, one of the centrepieces of the newly formed IBM Security Systems division. IBM announced the acquisition of Q1 Labs and the formation of the new Security Systems division in the same press release earlier this month.

The news was a bit pedestrian until I read the following:

"IBM is dropping the 'Tivoli' name from the Identity and Access Management suite"

Of course, I did a double-take. As an ex-Tivoli-ean who went around spruiking the virtues of TIM and TAM, I was taken aback. To quote the great John McEnroe:

"YOU. CANNOT. BE SERIOUS!"

Years of goodwill (alright, and some bad when stuff didn't work the way we promised they would - but we always fixed it) and brand awareness thrown away. It also means people will no longer be able to deliver one of these Tim Tams to the customer as a joke instead of actual Identity & Access Management software.

IBM Identity Manager and IBM Access Manager just don't have the same ring. The resulting acronyms are harder to pronounce, and downright confusing, respectively. IIM and IAM. Go around talking about "IIM" and people will think you missed a word and uttered something random in place of said missing word. Either that or they'll ask if you have something stuck in your throat and whether you'd like some water. Talk about "IAM" and people in security will assume you are talking about "Identity & Access Management", not "IBM Access Manager", which only partially fulfils the "AM" part of the real IAM.

This "IIM" and "IAM" talk presents a decent enough segue to the fact that the acronym for IBM's new Security Systems division is "ISS", as opposed to Internet Security Systems (ISS), whom IBM acquired over 5 years ago and then re-branded IBM Internet Security Systems (IBM ISS). The old ISS (Internet Security Systems) technology is no doubt going to be rolled into the new ISS (IBM Security Systems) along with the IAM (Identity & Access Management, not IBM Access Manager) suite that is no longer Tivoli and the Q1 Labs technology.

At this point, you may want to take a break. Your brain must be hurting from that last paragraph...

And, we're back.

While we're on confusing branding, which IBM is no doubt very good at, I'll take this time to note something else IBM is also very good at: bad product names. IBM recently released an add-on to Tivoli, oops, I mean IBM Identity Manager, called Role and Policy Modeler (RaPM). Gees, IBM. Why didn't you just call it "Role and Policy Enforcement Modeler"? I'll leave it to the reader to work that acronym out.

So, IBM, seriously...WTF?

Alas, it is with some sadness that I must now bid adieu to "TIM TAM" and welcome, rather begrudgingly, "IIM IAM". I just said that out loud. Must. Wash. Mouth. Out.

The Problem With Application Security

I've been pondering this for some time and wondering why it's so difficult to get application developers and software architects to care about security. Then it hit me:

They don't care to understand enough about security to care about it.

Recently, I talked to a VERY senior software architect who is in charge of a project for a VERY large company. The project deals with moving information between various data sources. One of these sources is the physical access control system. In other words, the component doing the moving of information would be a primary candidate for a hack should someone want to get somewhere in the building they weren't supposed to be.

Me: "What about security?"

Architect: "We encrypt the source data file that gets read."

Me: "And what happens when the data is being passed around between systems?"

Architect: "It's all on the internal network. We don't need to worry about security since it's all trusted."

Me: "So, there's no need for you to even ensure data integrity?"

Architect: "Why? What for?"

Me: "What if someone messes with the messages being passed back and forth between the systems?"

Architect: "Why does that matter?"

Me: "An attacker could change it while the data is in transit."

Architect: "That won't happen."

Me: "Shouldn't you at least sign the messages containing the data? It doesn't take much code to do it."

Architect: "No, we trust everything internal."

Me: "Does your project have anyone who is responsible for security?"

Architect: "I am."

Enough said.

Product Naming Confusion

You marketing types responsible for the constant renaming of your sub-brands in recent years (and are probably still doing it) have a lot to answer for. It's caused me a few headaches recently and I dare say lots of others that just haven't bothered to voice their displeasure.

It wasn't so long ago, that many of the large Identity & Access Management (IAM) vendors had sub-brands under their sub-brands before you even got to the real name of the product. That is no longer the case, but it's still a problem that will continue to hang around as long as we have marketing departments and products to sell. Many of the large vendors still do it, some with good reason. But most of the time, it just causes confusion.

What am I talking about? In the IAM space alone, we had IBM Tivoli SecureWay, CA eTrust and Sun ONE, to name a few. Take what is now known as Tivoli Access Manager. Back then, it was known as IBM Tivoli SecureWay Policy Director. Tivoli was better known as a systems management brand in those days, so the "SecureWay" brand made it clear that Tivoli had a set of security products.

What's beginning to happen now however, is that organisations that have legacy applications from those days and have not upgraded still refer to product by the old name, which would be slightly easier to deal with if everyone used the full name. Unfortunately, no one ever does for the sake of brevity.

Now, I'm not going to name any particular company as this could have happened with any of them. For this reason, let's take a hypothetical company, SCI, with a sub-brand called Onetiv, and yet another sub-brand of the Onetiv sub-brand called TrustWay. SCI, being a large software vendor, has lots of products. But it is quite well known for its SCI Onetiv TrustWay DodgyStandardWidget product, which has a standard, open interface called the DSW protocol. SCI has a few other products under the TrustWay banner which are still commonly used, but not as well known.

An organisation, DodgyBrothers, which uses one of SCI's products, has an external consulting team working on specifying a project which has to integrate with the SCI product in question. In the project specification, it states that DodgyBrothers uses SCI's TrustWay product. If you've been following this story along, you should be saying:

"Hang on a minute, which TrustWay product?"

But imagine I hadn't given you the background and that in your mind, you only know of a single TrustWay product: DodgyStandardWidget. Now, place yourself in the shoes of the technical analyst on the consulting team working on the specification for the project. The next line you write is going to say something along the lines of:

"And the integration into TrustWay is done via the standard DSW protocol".

Based on this project specification, an agreed statement of work was signed between DodgyBrothers and the external consulting company to implement the solution with a set of agreed timelines (based on project estimates derived from the specifications). Along comes the design team who then reads through the specifications and then proceeds to design the solution. As part of the design, the architect needs to talk to relevant teams within DodgyBrothers to gather information regarding each integration point.

When it comes time to speak to the TrustWay team, the architect is greeted with the response:

"What do you mean by DSW protocol? TrustWay doesn't support the DSW protocol."

The architect then asks the TrustWay team to send any documentation they have on the TrustWay product. Upon receiving the information, the architect is horrified to read the title on the first page: "SCI Onetiv TrustWay NotSoDodgyOtherThingy". The architect thinks:

"Maybe it's not so bad, perhaps it uses the DodgyStandardWidget product as the underlying store. Nope. Next. Ok, maybe there's an interface we can leverage to integrate with this thing. Nope. Now what? Oh, command line. S*$%."

I don't need to tell those of you with project experience what just happened. Project plan, blown out. Cost, blown out. Budget, gone. Change request? Let's hope the client agrees. Unlikely. It was the consultant's fault for not doing their homework. Or was it?

Yes, the technical analyst is to blame for not being thorough (due to an assumption they had no reason at the time to think was incorrect). But anyone responsible for using sub-brands, swapping them in and out and constantly renaming products thus confusing the heck out of customers has to accept some of the blame too.

Me? I'm just annoyed at having to be the one doing the due diligence after the fact and be left holding the lump of crap after you've all run away. Thanks.