I was working on an article on a holistic approach to data leakage, fraud and revenue leakage today.   Spend most of my Sunday, reading and trying to summarize some of the work we’ve done with our telecom service provider customers in Israel and Poland.
I came across a thread entitled What is the acceptable percentage of Revenue Leakage?
It was somewhat entertaining with nuggets like
“The simple truth is this.  So far, very few vendors are in the mode of caring about repeat business.  So they will make any promise to make a sale.  If they make some extravagant claim about total losses, but the product they sell delivers little or no value, then they are still happy because they got the sale.  What makes it worse is that people working in revenue assurance service providers will often try to cover up the failures of expensive projects, presenting them as a success even if they deliver little benefit.”
But the simple truth is that the same problem of talking about losses without talking about risk mitigation cost and effectiveness is also rampant in the information security world.  Vendors like Symantec, McAfee, WebSense and RSA  use pseudo-science to justify their products and FUD tactics when the pseudo science doesn’t work.

I just love these vulnerability curves.  I think that the only difference between the revenue assurance space and information security is terminology.   Vendors appear to be unconcerned with repeat sales and being able to prove consistent ROI over time.
However all is not lost. In the security analyst and research community there is a a growing trend to  model threats and damage to assets in dollar terms – since justifying budgets to the CISO is pretty hard with qualitative measures when products and services cost quantitative money.
Eric Priezkains talks about TMF publishing KPIs (key process indicators) for revenue assurance. As Eric notes in another post on his blog – there is a problem with generic KPIs:

1. There is a lack of consensus  on revenue assurance KPIs both with vendors and customers
2. Even if agreed upon in an industry group like the TM Forum; standard KPIs are not one-size-fits-all and what’s good for a large telco may be a poor fit for a Tier 3 operator.
3. Even with standards, customers may not have the data to measure the KPIs.

There is a similar situation in the compliance industry with standards like PCI DSS 1.1. The PCI Data Security Standard was written by a committee made up of big processors, Visa and Mastercard.  Many of the guidelines are out-dated – like making an anti-virus mandatory and calling it threat management or explaining how routers can be configured to be firewalls. I am not sure that this is security best practice any more and more importantly – standards written by big credit card institutions may not be suitable for small merchants.
There are three things we must have for security, compliance and revenue assurance:

1. Assess risk with a common $ metric;  anything else will be an endless debate
2. Prioritize mitigation; countermeasures must be cost-effective
3. Sell to decision-makers in language they understand.  Any executive will want to know that the revenue gains will exceed the investment in revenue assurance.