Royal Bank of Scotland inviting consumers to buying protection insurance

When customers confirm the receipt of a credit card at RBS; they are being invited to buy protection insurance under slightly dubious pretences. I listened into a call where a call centre operator called Daniel said:

"We notice that you do not have protection cover on your credit card. Did you know that anyone who has your name and date of birth can apply for loans and credit in your name and you will be liable for the full amount?"

Daniel at no point mentioned that he was selling a type of insurance policy until being prompted to by the caller. After some discussion the policy is subject to all sorts of small print that most consumers would not understand. He also did some rather silly scaremongering by suggesting that fraudsters could get passports etc in the name of the caller at the click of a button on a website and generally inferring that the responsibility for poor lending practices is the fault of the consumer rather than the lender. At that point I stopped him.

In the UK, the financial services distance selling rules specifically state that a name and address is required for consumer credit and the act has controls in place so that there is time to reverse a credit agreement. The Consumer Credit Act also has controls in place to ensure that the onus is on the lender to establish the identity of the creditor - crucially, it is not the consumer. The 3 large credit reference agencies in the UK are in business to help their clients do this.

This sales call was bordering on mis-selling of an insurance policy. If you are going to take out such a plan, read the small print carefully and understand your rights.

If you are the victim of identity theft then, get in touch with the credit reference agencies; here is a snippet from the house of commons written evidence:

If Experian has established that an individual is a true victim of fraud and their identity has been fully authenticated, they are provided with the following:

— A dedicated case worker (with a freephone number), who will give general and ongoing advice on identity fraud as well as dealing with the specific problems being experienced by that individual and helping to liaise with lenders on their behalf.

— A free copy of their credit report along with copies of Experian's consumer advice leaflets—Your Credit Report Explained and Identity Fraud Explained.

— A discrete password which is added to their credit report which ensures lenders are alerted to the fact that an individual has been an ID fraud victim and should therefore request the password prior to proceeding with an application for credit.

— Information about and referral to CIFAS (the UK's fraud prevention service) for Protective Registration.

— Free 12 month membership Experian's credit report monitoring service, CreditExpert.

Developing Security Requirements

I've just managed to get a set of "security requirements" agreed by my large financial client.

So why write requirements at all?

In a complex organisation where there are many system delivery departments with complex commercial arrangements including outsourcers and contracting organisations - writing a definitive set of standards for designing & developing applications can be

• too prescriptive,
  
• expensive - because telling 3rd party delivery organisations to "do it my way" is always expensive
• inflexible for the business.

Since mandating the implementation would be a risky endeavour - I've created requirements at a higher level that each of the organisational departments can take and use it to derive their own:

• training and awareness processes
• coding standards and quality gateways
• testing approaches and automatic review
  

Clearly, some of the departments will be more efficient by co-operating but some of the 3rd party suppliers will simply wind these requirements into their own delivery mechanisms. My clients audit staff then have a clear set of requirements to measure delivery projects and also measure the 3rd party suppliers themselves.

Rating and Prioritisation
My plan involved taking the OWASP Top Ten list, the PCI DSS standards and the FSA Treating Customer Fairly legislature and turning them into requirements; with each sub requirement rated with a MoSCoW rating. The MoSCoW rating system is standard for requirements in that it not only prioritises requirements but also allows the author to set custom measurement:

• Must Have: means that it the system does not meet this security requirement then the project has to stop as soon as it is known - the project cannot move forward.
• Should Have: means that the system has to design in to meet this requirement. If it cannot meet the requirement then the project can only go ahead if there is business, tech & risk agreement that the project can carry on.
• Could Have: means that the project have got to consider the requirement in the plans, but may drop it if it is too expensive. They have to give a reason and any risk exposure explained - but this is not scruitinised in the same way as a should have.
• Want, or Would Have: Aspirational security requirements that the business recognise as important but understand they will cost more, or might not be possible with todays technology etc.

I find it surprising that many security professionals that I deal with do not recognise RISK. They automatically will say YES, WE MUST HAVE all the security features without realising that the selection of the security features is a risk balance.

e.g. one organisation I worked for mandated fibre to every desktop because the risk or ethernet radiation leakage would be too damaging for their business. Clearly desktops in a financial insurance company do not require this - although, if the price was right then the business would have this extra security. So for one organisation it was a MUST, the other a WOULD HAVE.

What about the requirements that have been missed?
Sure, there will be some that have been missed. However, in my experience, the online applictaions that will generate huge breaches tend to show signs very early on that anti-patterns existed. Over-worked teams, poorly educated, poor communication etc etc,

By focussing the requirements on the OWASP etc, it gives auditors concrete foundations to measure the security quality of projects in a commercial context.

Example Requirement
ID: Z1.1 (in the AntiXSS chapter)
Name: Strong output encoding
Description: Ensure that all user-supplied data is appropriately entity encoded before rendering, taking the approach to encode all characters other than a very limited subset. This is the approach of the various Anti-XSS libraries. Also, set the character encodings for each page output, which will reduce exposure to some attack vectors.
Type: Security requirement
Source: OWASP Top 10, 2007
MoSCoW: MUST
Measure of Success: All input and output data must be encoded appropriately with the output encoding specified, e.g. UTF-1, ISO 8859-1