There's a lot of buzz about vendor liability for software vulnerabilities if companies suffer a loss of assets...
or data because of bad programming. Where does RSA stand on this issue? We stand firmly behind the strength and quality of our products as outlined in our product specification. Where I get concerned is when people talk in terms of the same type of product liability that other people would have with other types of consumer products. To legislate quality on that level into software where you have inherent issues is in my mind ill advised and would only play to the advantage of the American trial lawyers. So, I think it would be big business for lawyers. I think it would stifle innovation. I think it would slow innovation. I don't think it would be a good thing. Have you had a customer try to get RSA to assume any liability and have it written into contracts? We've had acceptance criteria written into contracts, which we would prefer to do in a pilot phase. And which we will certainly do. That's perfectly acceptable. You're not going to deploy a security product and say to our salesperson, 'I'll buy three million of those.' People tend to pilot our products first and that's OK. They do get a familiarity with it. When you get it into a live environment, it's never quite the same as the pilot environment. But by and large, they get a good feel for it. Are those points something that users may not understand, and they're just venting their frustration when they call for vendor liability? I think the software industry has to take responsibility for allowing some pretty shoddy products to get into the marketplace. Having said that, I know that we work extremely hard on our quality control. It's really incumbent on us to make sure that we're responsible for our own products, but I can certainly understand the frustrations of people who buy tech products and have incessant product or quality issues. We use our own products at RSA. RSA Security recently underwent some internal reorganization of product lines and staff reductions in light of recent quarterly revenue misses. Can you explain the impact, if any, of the reorganization to users? It really shouldn't impact users. It's more of an internal focus. What we've done is taken what was a horizontal organization where product management across all lines was run by one guy, engineering product lines across all lines run by one guy and made that into a product division where product management and engineering for authentication products are combined; where product management and engineering for developers of encryption products are combined and where product management and engineering for Web access management are combined. We believe that will give us more focus and more executive sponsorship for those various product lines. It's generally accepted that the expected spending boom on security technology post-September 11 did not happen? Why is that and do you see signs of that turning around? I'm not seeing any signs of an increase in security spending. The only difference pre- and post-September 11 is that the level of awareness has been built up. It's not like everyone said, 'No more passwords, we're going to use (strong authentication)' What all security companies are faced with is the continuing slowdown of the tech segments of the economy. Budgets are down across the board. Identity management is starting to gain traction in the security space as enterprises extend their business on the Web to partners, the supply chain and customers. What role will RSA will take in terms of innovation in that area. I want to distinguish first creating an identity and creating a trusted identity. The Liberty Alliance (RSA is a founding member of the Liberty Alliance) is designed to create a standard for identities. I would see RSA potentially, either through partners or on its own, getting in the business of provisioning those identities. In other words, how do you generate an identity based on a standard? Then, RSA would add value to what was created by a partner or on our own by adding the trust element. I can put a name into a database, and based on a standard, have that name recognized by three or four different entities. But, does that mean those three or four entities really trust that it's you. Creating the identity and provisioning it is separate from creating the trusted elements around it. So, you need to make sure you distinguish between the two. RSA has a role to play in all of it, because we will help with the development of the Liberty specification; we'll work with Microsoft on Passport; we'll work with partners that do provisioning. And then we will create the trusted element. Why has public key infrastructure (PKI) failed to take off? There are a number of factors. First, people bought an infrastructure without thinking about the application requirements or the problems they were trying to solve and they were disappointed in PKI. The user's authentication problem lies in how to protect the digital certificate that's issued. The digital certificate can often be accessible with a stack password. That's where a smart card and strong two-factor authentication is really necessary to protect the certificate. Another problem is that people don't have Web-enabled applications like they do client server and mainframe applications. Those applications are not understood by the digital certificate. We are seeing sharp declines in revenue for PKI for client servers and mainframe applications, but an increase in revenue for Web-enabled applications. It's important to go with the right authentication method for your business. Often, an SSL connection is enough.
FOR MORE INFORMATION
A recent SearchSecurity survey said that 56% of respondents said their infrastructures were more secure post-September 11.
I would probably attribute that to awareness. Or, they just never realized they had strong security products or a security policy implemented. It may have been a surprise to them. That also means that 44% don't believe their security infrastructure is stronger post-September 11.