TeleMedia Strategy
The Bleeding Edge of Disruption

Revenue assurance and fraud management has become a strategic imperative for communications service providers in the current down economy. According to lightreading.com the worldwide annual costs of fraud to carrier companies amount to anything between $70-$100 Billion, and telecom fraud is the single biggest cause of revenue loss for wireless operators. According to FINA, a leading fraud and security industry association, operators lose as much as 6-8% of their annual revenue to fraud. With current tightening of household budgets, 6% is not a number anyone can ignore.  This is above and beyond the costs of handling data breaches and insider threats - not to mention damages to the brand.

It is therefore not too surprising that while IT budgets have gone way down as a result of the global downturn, security budgets are actually up. In fact, security budgets always go up. It used to be primarily because good security is a must-have in order to operate a business. Later, the main reason became various regulations that operators had to comply with. It is very tough to go back to a regulator and tell them that you did not comply with mandates and hence had a data breach. But today, this is coupled with the third reason – the need to grow revenue by cutting down on the loss due to fraud.

There is one unfortunate behavioral pattern involving security and compliance. Because the last 5 years have been so dominated by regulations and compliance, many security organizations have put compliance ahead of security. While this is obviously wrong, it is very easy to see why this happens – it's just human nature. Good security is an amorphous thing and is not well defined. Compliance requirements on the other hand, are either pretty well defined or at least there is usually an external entity that interprets the regulation to a form that you can just “follow orders” - and people prefer to be told the scope of what to do than have to figure it out themselves. Because compliance became a main issue at an executive level and because it is easier to address than good security, many companies (sometimes unknowingly) addressed compliance and not security.

Of course, the two are very tightly related and there is a lot of commonality. However, it is very important to remember that good security DOES imply compliance while compliance with regulation (internal or external) DOES NOT imply good security. This may not be obvious – but is a well known fact to all security practitioners.

As an example, every year SANS publishes yearly predictions. Right at the beginning of the year SANS posted a prediction by David Hoelzer that a major corporation who is fully compliant with PCI/DSS will experience a major data breach (http://www.sans.edu/resources/securitylab/2009_predictions.php). And indeed, as described in (http://www.enclaveforensics.com/Blog/files/1c297703cb06cddea9b71a4b055adf03-21.html), Heartland Payment Systems announced that they experienced a major compromise, even though they are PCI/DSS compliant. [PCI/DSS is the Payment Card Industry Data Security Standard which defines technical and operational requirements that were created to help organizations that process card payments prevent credit card fraud, hacking and various other security vulnerabilities and threats].

OK – great – so let's be secure, not just compliant. The question is how to translate this very simple sentence to practical measures – and that's not that simple. It is a combination of good management/governance with technical best practices. Managers prefer compliance projects because they are very well defined – you have a target that is fairly clear and you know how to track progress. Best practices get around most of this issue – they give you a very concrete set of instructions that you can follow while their focus is usually wider than a single compliance requirement. There are a few good sources for best practices including Security Technical Implementation Guides (STIG - http://iase.disa.mil/stigs/index.html) and standards published by the Center for Internet Security (http://www.cisecurity.org/). 

Another good approach is to take multiple regulations and compliance requirements TOGETHER and generalize them all into one set of instructions, and implement that as a project rather than having to deal with multiple different projects all addressing one regulation. If you add to that good management and oversight/governance (and that is not a trivial thing), not only will you be far more secure but the project itself will cost less than the aggregate cost of the multiple projects.

By Dr. Ron

Dr. Ron Ben-Natan is one of the world's foremost expert on information Governance, Risk Management, and Compliance (GRC), secure application delivery, portals, and data security.  He has more than 25 years of experience developing and implementing distributed systems and security technologies. Ron is currently Chief Technical Officer at Guardium, the leader in database security and auditing where he has built the most widely deployed Database GRC platform within telcos. He has been involved in numerous security and GRC implementations across both BSS and OSS.

Prior to Guardium,  he worked for companies such as Merrill Lynch, J.P. Morgan, Intel and AT&T Bell Laboratories. Ron has been named an IBM GOLD consultant, a level that is currently held by less than 75 people worldwide.  He has authored and co-authored 11 technical books including "Implementing Database Security and Auditing", "How To Secure and Audit Oracle 10g and 11g", "Mastering IBM WebSphere Portal", and "Integrating Service Level Agreements: Optimizing your OSS for SLA Delivery". Ron frequently speaks at database and security seminars.