CRM system misuse is difficult to detect with standard security measures, but this is a textbook example of why database activity monitoring systems were invented.
I began writing homegrown activity monitoring tools in 1998, specifically to detect misuse of the brokerage CRM systems I managed. Through a combination of database triggers and network monitoring, the specific use cases I needed to address were brokers looking at a number of records that were "owned" by other brokers, or when a broker looked to be downloading a large percentage of the database. Our brokers commonly served multiple products and multiple geographic locations, so the trick was differentiating between normal behavior and suspect behavior. The commercial intrusion detection systems (IDS)lacked any of the business context to differentiate between normal and suspicious business transactions. CRM misuse is, to me, the very genesis of the database monitoring market.
Since that time, DAM platforms have undergone several generations of maturity, offering much better performance and analysis capabilities. But use of DAM products for SaaS services remains rare. Service providers still rely upon access controls, looking at the IP address in association with the users account during login in order to detect compromised credentials. And this approach remains effective at catching shared credentials used in different locations -- provided you only permit your customer to be in one location. But this is an outdated assumption with salespeople likely to be on the road, using any wireless hotspot they can connect with. That means a different IP address every day. Reliance on network-based detection is speculative at best.
The problem of sharing credentials is really common. You want to help a friend, so you give them a login to help solve a problem. But odds are that they use the account the next time they need a quick answer. Few people go to the hassle of changing their password to stop a friend from using the account again. Password rotation helps block the causal mis-user who was provided credentials and merely wants to view information to help them make business decisions. But odds are pretty good their friends and family will give them the new passwords as well.
Password policies do not address account hijacking, cases where data is altered, or detect a user downloading an entire copy of the database. Unless Ipreo was monitoring usage, their claim for damages will be sketchy at best. Their access control system saw valid credentials, their gateways see an IP address, but unless they engineered their applications to record data queries, they may not be able to prove data was actually viewed.
If a database contains valuable enough data, it's a safe bet it will attract the purely malicious attacker. Downloading credit card numbers to be sold or used in a fraudulent manner, altering accounts for financial gain, or monitoring inside information for stock trades are all malicious acts that go undetected by access controls, intrusion detection and most auditing systems. With more firms offering services over the Internet, or even in the cloud, we cannot differentiate between insiders and outsiders.
With SaaS, all of your users are outsiders. IP addresses can be faked, so the association of appropriate IP addresses in conjunction with a specific accounts is no longer a viable method to detect account hijacking. If Ipreo is serious about misuse detection for their database and doesn't want to allow shared account usage to go on for years, then they need to look at monitoring database activity.
If the database is how you generate most of your revenue, don't you think you should watch over it?
Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading.