In 2005, the US Federal Financial Institutions Examination Council (FFIEC) published Authentication in an Internet Banking Environment building on their earlier work on electronic banking. A supplement to the 2005 guidance has now been published.

The 2005 guidance recommended periodic risk assessments so that control mechanisms can be adjusted to respond to changing internal and external threats. The guidance stated that authentication techniques should be appropriate to the risks associated with the product or service, but that single-factor authentication is inadequate. It also recommended building customer awareness, and minimum supervisory expectations for authentication controls relating to high-risk online transactions involving customer information and the movement of funds to other parties.

On 28th June 2011, the FFIEC announced its Supplemental Guidance on Internet Banking Authentication to reinforce the guidance's risk management framework and update the expectations for authentication, layered security and other controls in an increasingly hostile environment.

The supplementary guidance reiterates the need for risk assessments and authentication for higher-risk transactions. It also recommends a layered security approach "since virtually every authentication technique can be compromised". Its recommendations for layered security controls include fraud detection & monitoring, dual device authentication, out-of-band verification, positive pay & debit blocks, transactional limits, activity limits, geo-location IP address reputation monitoring, policies & processes for handling compromised devices and malicious users, monitoring of account maintenance activities and customer education.

So, useful information, and not just for internet banking. The guidance is a good reference source for anyone considering authentication controls for access to more sensitive information.

Thank you to Alexis Fitzgerald for bringing this document to my attention.

Whilst on the subject of new information security reports from WhiteHat Security and Veracode, here is another one to add to your reading material.

The 2011 Data Breach Investigations Report examines data from data breach investigations for Verizon's customers. So, a lot wider than application security, but useful reading.

The information about how long it takes from point-of-entry to compromise, and compromise to discovery are interesting. Especially when the vast majority of data breaches are apparently discovered by third parties — not the target of the attack themselves.

Will that be you?

In my previous post, I mentioned the lack of data on return of investment (ROI) concerning building security into the software development life cycle (SDLC). Well after commenting on the Aberdeen Group report earlier this week, another study has been published by Forrester Consulting.

The report State of Application Security - Immature Practices Fuel Inefficiencies, But Positive ROI Is Attainable was commissioned by Microsoft to survey influencial people in software development in the United States and Canada. Appendix B of the report defines the demographics of the 150 people — there is a heavy bias towards people working in the "high tech" industry sector (rather than say financial, utilities or manufacturing) with more than half their organisations having annual revenue in excess of $5 billion including the development of software products and services.

The study examined the secure development drivers, practices, effectiveness and maturity. Table 1 in the report identifies that almost half of the organisations use their own software security methodology, with others using CMM/CMMI, Microsoft SDL, OpenSAMM and DISA STIG.

The conclusions? Most of the organisations surveyed have implemented some form of application security measures, but these are not yet mature and risk is still most commonly transferred from development to operations, where the remediation costs are highest. Tactical approaches with point technologies are less effective than prescriptive application security methodologies applied strategically throughout the SDLC. Those using a more coordinated, prescriptive approach reported a better ROI for application security. However, the ROI for these organisations is not has high as suggested in the Aberdeen Group study.

Last week the UK Information Commissioner's Office (ICO) announced a draft Data Sharing Code of Practice beginning a 12-week consultation process.

The new code aims to provide clear guidance to protect the rights of employees, citizens and consumers under the Data Protection Act when organisations undertake systematic/routine and exceptional ad-hoc data sharing. By improving data sharing arrangements, the ICO hope that both organisations and people can benefit from increased confidence in the processes and reduce the risks to personal data such as from data theft, loss (i.e. data breaches) and unauthorised alteration or destruction. The Data Sharing Code of Practice Consultation Paper explains what data sharing is, the difference between legal requirements and best practice, provides information on security, governance and, for public sector organisations, free of information.

The draft document has been produced in a clear easy-to-read style which will be familiar to those who have seen other recent ICO guidance documents. Where necessary, explanations are included within the text rather than as references external sources (e.g. the eight data protection principles, individuals' rights, ICO powers and penalties).

The document also includes nine short case studies which illustrate data sharing issues, but perhaps further private sector examples, and those related to more common day-to-day activities are required. These might negate the need for an additional Data Sharing FAQs document. Section 14 provides a template for a suggested data sharing protocol between organisations and will be a helpful start for most organisations.

It is worth reading now and responding to the ICO with any suggestions for changes or additions. If it raises questions in your own mind, send those too. An improved document will help you, your suppliers and your customers improve data protection standards and increase awareness. The ICO has produced a list of consultation questions—responses to the consultation can be sent by email or post. The consultation closes on 5th January 2011.

Update 20th October 2010: See follow-up post about companies' powers to share data.

The UK Centre for the Protection of National Infrastructure (CPNI) have published new guidance on understanding and managing the risks from phishing and pharming.

Whilst most readers of this blog won't work on projects considered part of the national infrastructure, that doesn't mean you should ignore good, free advice.

The CPNI document discusses the threats and impacts (on employees, customers, clients and citizens), the modes of attack and possible countermeasures. I'm pleased to see that countermeasures to reduce the likelihood of successful attacks include both technical and cultural measures. Measures to mitigate the effects of successful attacks are also discussed.

Although some of the document is necessarily technical in places, the case studies in Appendix C should make sense to everyone. Remember, this is about business risk, not technical risk. The "I don't understand technical things" argument does not stand up.

Of course, assessing and implementing information security policies and controls is hardly ever simple or quick. But with the government's aim to reduce the number of different web sites this process may be a little easier. It's good to see such guidance, especially when the Central Office of Information (COI) has to date avoided the subject of security in its own web standards and guidelines. In view of the perception that the government isn't keeping up with threats (for example see the response to the petition to upgrade away from Internet Explorer 6), how are the CPNI phishing and pharming countermeasures being implemented by the government?

Knowledge about the degree to which the cultural countermeasures have been adopted within the government sector cannot be adequately measured from outside, and it would be good to see these included in work performed by the National Audit Office. Similarly most of the technical countermeasures would require privileged access to government networks (and permission!). However "use of SSL and TLS" and "signing of digital communications" should be easily observable, without doing any testing, from the outside world.

These two measures have security benefits beyond protection against phishing and pharming. They can assist citizens wanting to verify the identity of, and rely on the integrity of the information they see on what looks like a government web site, or receive in an official-looking email or other form of correspondence, perhaps during a national emergency. These types of event can attract themed phishing attacks for example. I haven't received any official government electronic communications recently apart from reminders from HMRC about tax deadlines and the like, so can't comment on how the sender and data integrity is verified. The tax reminders don't contain any sensitive data, and occur when there are known forthcoming business events or relate to actions undertaken by myself, so correctly don't need the same degree of verification.

But anyone can visit a web site, so what about those? Well, the CPNI web site appears to also be available over SSL/TLS as we'd expect. But, looking at https://www.direct.gov.uk using SSL (now more correctly called transport layer security, TLS) in the Chrome web browser, I was a bit surprised to see:

and this is the same for the prime minister's web site at https://www.number10.gov.uk/. Another possible primary governmental address is https://www.hmg.gov.uk which gives:

Maybe these have been deemed to be acceptable risks. But let's hope the other recommended countermeasures have been implemented.

This year I have mentioned web application security programmes, how software vulnerability testing recommended risk-based, application security programmes and generalised results from a survey about web application security programs.

But what are enterprises doing in real life and what are the issues? During the second day of OWASP AppSec Research 2010, Michael Craigue of Dell presented on Secure Application Development for the Enterprise: Practical, Real-World Tips. Although I missed it, people who did attend this track were enthusiastic about it and the video recording has now been published. I watched it last weekend.

Michael described Dell's 10-strong Global Information Security Services group and how it works with 3,000-5,000 developers in internal teams and how their appsec work is built on a published and maintained secure application development standard. Some of the problems encountered at Dell were platform diversity, security expert retention, the need to develop self-help documentation for the low and medium risk projects, lack of good metrics around security awareness training, high overhead of conventional threat modelling and the need to build security into the development lifecyle slowly, and in a business-focused manner.

At Dell, the project risk is calculated from ten factors including data classification, compliance requirements, whether it is externally facing, and the security knowledge of the development team. Interestingly, in the final questions from the audience, Michael mentioned Dell are using Open SAMM to identify gaps, measure how well their security programme is performing and to focus improvement efforts. Even projects that the group does not get involved with directly, are subject to quality checks and audit such as using Control Self Assessments (CSAs), which look for the artifacts required in the self-help documentation, even for low-risk applications.

There is another description of how software assurance practices at Ford in 2009, and recently published on US DHS's best practices web site Build Security In. The Ford programme is quite different. Every application security programme is unique because every organisation's culture, application and acceptance of risk is different.

What is yours like?

Continuing on the theme of confusing users, Security Dialogs and Graphics discussed the multitude of inconsistent styles for security warnings on web sites, mobile applications and in email.

This is usability hell. Why should each device, browser and application choose how these messages are worded and displayed? I mentioned previously the contributing factor of tab colouring in IE8 and a recent post Tabnabbing: A New Type of Phishing Attack demonstrates how users can be tricked into providing sensitive information to the wrong web site. But it's not just inconsistent technical implementation that matters; the humans in the process matter too.

Last week I came across two web sites in my normal business usage that gave me invalid SSL/TLS secure certificate warnings, and these weren't little businesses that might not know any better—both are multinational enterprises—one a UK bank, and the other a UK mobile phone company.

1. In one case a registration process used a domain www.[subdomain].[company].co.uk whereas the certificate was for [subdomain].[company].co.uk
2. In the other, the company had recently been taken over and the site was using www.[oldcompanyname].com whereas the certificate was for www.[newcompanyname].co.uk

But what surprised me most was the response I received when reporting these problems to the respective site owners. Neither organisation had a clear process for sending details of possible security problems and therefore the responses seem to have been directed through customer support channels.

One provided the initial response:

and:

and even though I re-explained the problem, and that it hadn't stopped me from doing what I wanted:

and then:

and the rather indefinite:

and then back to asking me to supply screenshots, my username and details of my browser:

Mmm.. and still no idea about the issue:

My issue? Their issue I believe.

The other company suggested it was the date/time on my own computer which was the fault:

and some advice about security:

at which point I rang them up, and stumped them by quoting their own tracking number. No further call back from them yet.

I found this all rather depressing. How can we expect customers (end users) to take care with security if the understanding and processes are not in place within the organisation, especially with customer-facing staff? Organisations like Get Safe Online and Card Watch are trying their best to educate people, but the web site owners need to play along too. So here's a quick checklist, including a couple of new items:

1. Obtain your own domain like example.com or example.co.uk (not a sub-domain of someone other company e.g. example.uk.com)
2. Provide security training to web site architects and developers
3. Determine how SSL/TLS will be applied on the site
4. Buy a certificate and apply SSL usage appropriately through the site
5. Verify the proper usage of SSL and session management
6. Verify the correct SSL configuration
7. Include SSL/TLS certificate management in change control processes
8. Provide awareness training to customer support staff about what "secure web site" means and the types of enquiries customers may have
9. Give some basis security advice to customers and direct them to other resources for more information
10. Ensure there is a simple way for people to inform you of security concerns and possible incidents such as phishing, browser security warnings, compromised credentials, account mis-use, etc.

Please—I don't want to have to go through customer support again! At the time of publishing this post, the certificate problems still exist.

Today I was looking around for UK energy providers, and came across this home page from one of the major suppliers:

Can you see what's wrong? I don't think "hello test" should be there. It's not humorous enough to be an April Fool's Day joke, and the page footer suggests the text may have been there for a couple of weeks:

I've mentioned previously test and old pages being found by site searches, but having test content on a PLC's home page is fairly bad. What will potential new customers think? If this appeared in a company's printed brochure, would heads roll?

Was the web site hacked or was it just some poorly thought-out testing? I suspect a hacker might have added something a little bit more malicious than 'hello test' so the implication is the content was added by an authorised person. I'm worried that the live site is being used as a test platform and that content can be added without review or approval. Also, why has site monitoring not picked up on this change?

I tried to "email" the company concerned but their web form insisted I had to be a customer, so I rang a telephone number instead which again asked for an account number. I eventually got through to someone and explained the problem. It's been "passed to the IT Department". Really? Not PR or Marketing?

Don't make it difficult for people with good intentions to tell you about concerns, possible security incidents or phishing emails—help them to do it easily and quickly. You'll benefit. Why do you think food manufacturers try to encourage you to contact them about complaints, rather than leaving you to speak with your local trading standards department?

Update 14:30 hrs: No change yet—let's hope it wasn't a hacker and digital forensics are beginning.

Update 16:40 hrs: The text has been removed.

The review of safety at BP's Texas Refinery following investigation and report on the explosion in 2005 which killed 15 people, injured 180 and caused substantial property damage, included a recommendation to use pre-startup safety reviews (PSSRs).

We can all learn lessons from unfortunate incidents like this in other disciplines (e.g. also the sinking of the MV Herald of Free Enterprise in 1987). Do web site developers and designers have an equivalent pre-launch security review (PLSR)?

I remember once reading an email press release about a new web site, only to visit it and find out that within a few link clicks you ended up in some sort of CMS admin area; we stopped browsing immediately and contacted the site's owner. In the past I have also been asked to make a web site live on Friday afternoon at 4pm; the answer has to be "no".

What should a PLSR include for a new or revised web site? If you don't already have a security policy, standards and procedures, here is a checklist of suggestions:

Not all these checks will be needed for your project but the order in which they are done is important. For a small web site with little functionality, this doesn't have to be complicated. For example, the build documentation and disaster recovery plan could mean having a full set of source files (pages, scripts, images, etc), each night's full backup of any changing data (e.g. database and generated files), login credentials, some notes on the server's configuration and contact details for the domain name registrar, design agency and hosting company.

For any project, try to discuss launch as early as possible in its lifecycle—preferably at the bidding/tender stage, but if not, immediately on project initiation. Define the launch/release criteria well in advance. Find out what the client and project owner's expectations are and who will be responsible for what. A good launch takes time, so make sure the team have enough time to complete the launch and subsequent checks without it running into abnormal hours of the day. Your web site project's failings might not lead to people's deaths, but that doesn't mean sloppy configuration, launch and operation are acceptable. What standards do you have?

Please let me know if you think anything should be added to or altered in this launch checklist.

PS if you are looking for a launch checklist that addresses wider website issues, I'd recommend the The Ultimate Website Launch Checklist.

This week the Ministry of Justice published the summary of responses to their consultation on revised fines for serious breaches of the Data Protection Act.

In Civil Monetary Penalties: Setting the Maximum Penalty proposals were made for a maximum £500,000 fine following granting of powers to impose civil monetary penalties being added to the Data Protection Act (DPA) 1998 (Sections 55A to 55E) by the Information Commissioner's Office (ICO) through section 144 of the Criminal Justice and Immigration Act 2008.

The 52 submissions described in the summary of responses showed broad agreement for fines up up to £500,000 for data controllers who seriously contravene data protection principles. The ICO issued a press release Data Breaches to Incur Up To £500,000 Penalty on the same day with details of how they will consider:

• the circumstances including the seriousness of the data breach
• the likelihood of substantial damage and distress to individuals
• whether the breach was deliberate or negligent
• what reasonable steps the organisation has taken to prevent breaches.

The ICO has produced statutory guidance about how it proposes to use this new power, which has been approved by the Secretary of State for Justice, and has been laid before Parliament.

The statutory guidance is worth reading since it outlines things such as "reasonable steps the Commissioner expects the data controller to take" that include (in a non-exhaustive list that includes mention of risk assessment, governance, audit, policies, procedures and practices):

So, the standards are being raised.

Subject to Parliamentary approval, the civil monetary penalties are expected to come into force later this year on 6 April:

• Draft Order "The Data Protection (Monetary Penalties) Order 2010"
• Statutory Instrument 2010/31, The Data Protection (Monetary Penalties) (Maximum Penalty and Notices) Regulations 2010

P.S. If you are interested in privacy matters, The EU's Article 29 Working Party and Working Party on Police and Justice have jointly published a paper on The Future of Privacy (WP 168) and there is an excellent summary and overview on the Tech and Law blog. The conclusion: a new comprehensive legal framework for data protection is needed in the EU.