CA continues to round out their security portfolio

Lots of interesting things happened last week in the information security space. This was largely due to the RSA Conference and the number of company announcements that coincide with it each year. Of course, Oracle stole much of the thunder by announcing their acquisition of Sun Microsystems. I've chosen not to comment on it because there's enough speculation out there (some informed, some less so). Also, I would have sounded like a broken record because any analysis on my part would have sounded very similar to my piece on the potential IBM and Sun deal that eventually fell through, but with an Oracle spin.

From a large Identity and Access Management (IAM) vendor standpoint, the most interesting piece of news actually came from CA. In fact, the only bit of IAM vendor news came from CA because the others didn't announce anything at all (I don't count "what the heck is going to happen to the Sun IAM stack" as news because at this point it's all speculation and is very much dependent on what Mr Ellison and his cohorts decide to do once the deal closes and the dust has settled).

I've written about how CA has been running faster than their competitors since late last year and they haven't stopped if the latest announcements are anything to go by. They actually made 3 announcements around RSA; the first was a pointer to Dave Hansen's (Corporate Senior Vice President and General Manager of CA’s Security Management business unit) keynote at RSA (the video of the keynote is here), the second I'll talk about in the next paragraph and the third related to a survey conducted by CA which Dave also referenced in his keynote.

The second announcement was the most interesting as it involved news around their portfolio, where they announced 3 new products:

• Enterprise Log Manager - a brand new, internally developed product
  
• Role & Compliance Manager - from their acquisition of Eurekify
  
• DLP - from their acquisition of Orchestria
  

Note: The DLP acronym generally stands for Data Leakage/Loss Prevention

I spoke to Dave Arbeitel (Vice President of Product Management for the Security Management Business Unit) about the new products late last week and got to find out a little bit more.

I hadn't actually noticed this but Dave pointed out that CA's approach to security management is now solution-focused and grouped as follows:

• Data & Resource Protection
• Identity Lifecycle Management
• Secure Web Business Enablement
• Security Information Management
  

The large IAM vendors are split between being product-focused and solution-focused and the approach taken is very much dependent on the overall company strategy. One thing I should note is that being solution-focused is fine as long as you don't get too smart for your own good and confuse customers (as I've accused IBM of doing on occasion).

Each of the 3 new products fits into one of the solution categories. My interpretation of the solution areas is that CA seems to have grouped what they deem to be the most complementary products together. The most interesting thing to note is that they've grouped CA Access Control together with CA DLP. This makes sense and is evidence that CA gets DLP and are starting to implement a strategy around how IAM and DLP can work together effectively. I'm not saying they get it completely yet, but this is not necessarily a bad thing. The industry as a whole doesn't quite understand the IAM/DLP/Data Security overlap at the moment. At least CA are trying to work it out by putting their money where their mouth is. But I'd caution them against putting too much of a marketing spin on things because people (like me) will call them out when required.

They key thing Dave wanted to get across was that CA has a broader security management strategy and these product announcements are simply steps along the execution path. This has been apparent to those of us following the market over the past couple of months and if CA keeps going, they're going to do just fine as long as they execute well.

I didn't get too much into product features of the Role & Compliance Manager and DLP products with Dave because Eurekify and Orchestria had relatively mature products. There wasn't much point in trying to pick those products apart. The only noteworthy change was that CA combined Eurekify's products into the single product (for those that are unaware, Eurekify had a separate compliance management product that integrated with their role management product). Dave also noted that the new products were not just a re-brand. CA's done additional development work to add functionality and integration points into the existing CA IAM suite.

While we're on the point of integration into the existing IAM suite, I'd like to pinpoint the supposed deep integration and "identity-awareness" of the DLP product. I had a chuckle watching Dave's keynote (and it wasn't from watching the almost cringe-worthy parody of "The Office"). During the demo, they supposedly showed identity management and data security integration. For anyone who hadn't seen a DLP product in action, it looked pretty slick/impressive.

As someone who has demonstrated a DLP product hundreds of times (maybe even thousands - I lost count after a few months) I can tell you that most of the demo only showed the DLP product in action. The solitary identity bit was the de-provisioning of the user (Dave) from a role (which took away access to the SAP application in the demo). Apart from the fact that CA Identity Manager probably has a standard connector into CA DLP to provision and de-provision access for users, they weren't doing anything in the demo that anyone else couldn't do by taking a decent provisioning product and building a connector into a good DLP product. Unfortunately CA, this isn't what I'd call identity-aware-DLP. I realise I may be dismissing other potentially (but unknown to me) nice integration points between DLP and CA's Identity and Access Management suite but I'm going based on the demo and calling it as I see it.

I did try to dig a little deeper into Enterprise Log Manager's features however, mainly because it's brand-spanking new. The only problem with Security Information and Event Management (SIEM) products is that you can't really get a handle on how good a product is until you get your hands on it. Dave assured me that installation is a breeze and that it can even be deployed as a virtual appliance, which I have no reason to doubt. From a technical standpoint, this is not difficult to achieve.

Good SIEM products tend to be measured by the ease of integration, number of standard collectors to other systems and reporting capabilities. The questions I asked Dave were driven by these factors and I gathered that Enterprise Log Manager is still very much a 1.0 product (that is, fairly immature). As an example, Dave mentioned that the product was tightly coupled with their IAM solutions. CA is probably referring to the fact that they can reference policies defined in some of their IAM products (although I'm not sure how deep or wide this integration runs) and have Enterprise Log Manager report on policy violations. But from a customer standpoint, I would expect that this also means I can point Enterprise Log Manager at any CA IAM product and have it be able to collect all relevant user events and report on them without much effort. Unfortunately, this is not the case (I'm sure CA will correct me if I misinterpreted Dave's comments). There needs to be some level of work done to have collectors that can pull information out of the other CA IAM products.

This is not to say there aren't any standard collectors, but I got the impression that this covers the main operating systems and some standard security devices but not much else. The thing about a lack of collectors however, is that the issue fixes itself over time because the more a product is deployed, the longer the list of standard collectors gets. CA needs to build standard collectors for their other IAM products sooner rather than later (I would start with Access Manager, Access Control and DLP). You cannot claim to have tight integration with your own suite of products if you don't at least have these products sorted.

The reporting capabilities seem to be a little more fleshed out. The vision for reporting is that customers use a combination of standard reports, services and new report packs that CA sends out from time to time. The list of standard reports includes many of the usual regulatory suspects, but in my experience these types of standard reports tend to need customisation to meet business needs. For customers that don't feel like using the standard reporting interface, there is a level of integration with SAP BusinessObjects Crystal Reports.

I'm not trying to belittle CA's SIEM efforts. They obviously see SIEM as part of their strategy, but they are a little late to the party on this. It doesn't preclude them from trying however, and at least they have now arrived at the party. I think they knew they weren't going to get a market-leading product at the first attempt. They made the decision to build the product from scratch and they would have been foolish or delusional to expect a world-beater at the first attempt. It does seem a little puzzling why they didn't choose to acquire a leading SIEM player and went with the build approach instead.

As is the norm with these discussions, I tend to ask about things not related to the news at hand as we move past the main items of discussion.

My first unrelated question related to the IDFocus product they acquired and whether any part of that solution made it into the 3 new products. The answer was no because even though it has some level of potential integration with role and compliance efforts, it fits best into the Identity Manager product where it helps to link business processes with provisioning requirements.

My second unrelated question was around the notion of having a central policy management point for all the products (like Symantec and McAfee are trying to do with their own products). The point of this question was to gauge if CA's strategy includes the centralisation of policy management. I didn't expect much because it's actually a VERY difficult thing to do and very few of the large IAM suite vendors have the appetite to invest in this area. I'm not talking about the engineering aspect, which is simple when compared to the actual analysis behind how one would rationalise all the different ways policies could be represented and trying to figure out how to apply an over-arching model to a large portfolio of products. Add DLP to the mix and it gets exponentially more complex because of all the data-centric requirements. For the record, Dave's answer was that the focus shouldn't really be on having a central policy store or management point. It's more about having the right processes occurring between the IAM products to ensure the correct policies are in place at the points where they need to be applied.

Overall, I think CA's got the right idea in terms of strategy. Whether their products are able to deliver remains to be seen. They've got some serious integration work to do so they can get a more coherent story out there and have products that deliver on the promise they are showing. CA does have a trump card to play that their competitors don't have (yet), and that's the DLP product. As I've said before, identity and data security go hand in hand.

Why do large companies like helping phishers?

It was stupid bank behaviour that compelled me to start blogging a few years ago. I've also noted the questionable ways which banks in general deal with customers from a security standpoint (although my bank's recently cleaned up its act somewhat).

Its not just the banks that help to facilitate phishing scams with their antiquated, unsafe processes when dealing with customers. Almost every large institution that holds personal data does at least one thing in an unsafe, insecure way. And almost every organisation that has a call centre forces us to divulge personal (and often account security) details to the person we speak to on the phone before they are "allowed" to access our account. This is not particularly safe either as the person on the other end of the line could very well take down the details and use them later (aka the most common argument against offshoring call centres). But there is a certain level of trust because most of the time, we call a number that we have used in the past and know with 99% certainty belongs to the organisation we mean to be dealing with. It's also the way the process works and we have learned to live with it despite the flaws.

A large amount of the blame here lies in the imbalance when dealing with personal information and the organisations we provide them to in return for a service. Companies have way too much power (and consumers little or no control) when it comes to our information, but I'm going off-topic here as I don't mean to be talking about Vendor Relationship Management (VRM). Back to the topic at hand...

I recently contacted my mobile service provider (from here on in, known as "Stupid Phone Company (SPC)") to change something about my account. First of all, the IVR system made me authenticate myself before patching me through to the warm body at the other end of the line who then proceeded to ask me exactly the same questions I had just provided to the system. I wasn't in the mood to rant at the person as they weren't to blame. They were simply doing their job. Process fail number 1: Why bother having the IVR system waste my time and authenticate me when the fool at the other end of the line is going to ask me the same thing again SPC?

In any case, the person couldn't help me. They said I had to notify the company in writing either via snail mail (what decade are we in SPC?) or via a form on their website. I took the online form option and didn't hear back for a few days.

Today, I received this in my inbox:

"Hi Ian,

Hope you are doing fine.

I’d like to help you Ian, however; for this I will need to access your account and currently I am unable to access your account due to security reasons.

In order for me to access your account and check the details on your account, please confirm the security details given below:

PIN (1st and 2nd digit)
Or
Full address with postcode
Date of birth
Method of payment

I assure you I'll be able to sort this out as soon as I receive this information.

I look forward to your response.

Kind regards,
(Name redacted)"

At this point, the only form of assurance I had that this came from a legitimate source was the "from" address in the email header. This however, isn't exactly difficult to fake (as my first year University lecturer demonstrated to us in ohhh, week 1 of "Computing101"). In other words, I have no assurance that it's from SPC. In fact, it even reads like a phishing email.

Being the paranoid security person that I am, I picked the phone up and called customer service to validate that they had indeed sent me an email and to double-check the email address I had to send the reply to. After questioning the poor customer service person and eventually getting them to agree that this process is ridiculous and insecure, they still insisted they could not get around the process and that this was the only way of getting my issue resolved because my request could not be met over the phone.

So it seems that this is the standard procedure when one fills in an online form with this company. In which case, they are exposing their customers to a security nightmare by building phishing-like behaviour into a standard procedure that all their customers will probably need to use at some point. Did you hear that SPC? Your BAU process is the same as the one phishers use!

I've actually visited this company in a professional capacity (in one of my previous jobs) and can confirm they do indeed have a security procedures and operations department. In other words, "we don't pay people to think about these things" is not a viable excuse. Someone there needs to be fired (and it's not the customer service department).