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.

The next Open Web Application Security Project (OWASP) London meeting is this week.

The London chapter meeting is on Thursday 14 January 2010 in EC1. Everyone is welcome, but you need to register first (free).

There will be talks on Top Ten Deployment Mistakes That Render SSL Useless by Ivan Ristić and Using Selenium to Hold State for Web Application Penetration Testing by Yiannis Pavlosoglou, who recently joined the OWASP Global Industry Committee.

Unfortunately I am unable to attend the meeting but hope to read the presentations afterwards.

It's common for access to some web sites to be restricted to users from particular Internet Protocol (IP) addresses. This is usually in addition to some other identification and authentication method. But other IP addresses are often added to this "allow list" and these should not necessarily be trusted in the same way.

In a typical scenario, a web site hosted on the internet that is used to administer another web application might be restricted to the company's own IP addresses. Then the developers say they need to check something on the live site, or another server needs to index the content, or someone wants to work from home for a while, or the site needs to be demonstrated at a client's location. All these additional IP addresses are added to the "allow list". These restrictions may be being applied at a network firewall, traffic management system, at the web server, in the application itself, in intrusion detection systems or in log analytical software, or in many of these. These are difficult to manage and in time there will be many IP addresses that no-one knows why they are allowed unless they are carefully documented, and subject to a fixed time limit when they are confirmed again by an appropriate person or removed. These extra addresses are quite often hard for someone else to guess.

However, there is another area where IP addresses are added to "allow lists", and this is for remote monitoring and testing services. These might be checking uptime, response times, content changes, HTML validation or security testing. The service providers publish the IP addresses of the source systems so that companies can specifically allow access to their web sites. Since the number of these services is relatively small, it's not too difficult to find which one might give access to areas of a web site or web application that the public (and malicious people) should not be able to get to. The particular danger here is that the IP addresses might be excluded from monitoring and logging, and therefore even a diligent web site manager might not realise for example the uptime monitoring service is making unusual, or excessive, requests.

Although it is not likely a malicious person is using this "trusted" address unless routing has been compromised as well, problems can go undetected, from what might seem to be a legitimate source. The IP address may have been typed incorrectly, or worse, the restrictions/exceptions may not have been implemented correctly allowing more addresses to have the privileged access than intended. Not logging a user's session is privileged access.

Allow traffic through, but be very specific what is allowed and monitor what's going on. Review all the exceptions periodically. Be especially careful about anything that bypasses authentication (such as allowing a search engine to crawl restricted-access content) on an otherwise public site.

At this time of the year, gardeners have usually seen the best of their summer displays, and thoughts turn to tidying up the garden before the winter.

The publication of a new report from the Ponemon Institute on Data Security in Development & Testing is a timely reminder that like gardens, our web site and web application development and test systems need periodic attention, otherwise they can go wild too. The report describes the findings from a survey of IT practitioners in the United Kingdom and United States on the adequacy of their policies and technologies in place to protect real data used in development and testing. The survey is included in the report, so you can compare your own organisation.

Take some time to identify how real data are being used in your development and test systems, and determine what sensitive data is being used, stored, transmitted and how it is deleted. Are you allowed to sue the data for development and testing? Check who has access to the data, from where, and what the risks are.

If you undertake some form of masking or other anonymisation technique, do read and take into account a new summary of research and discussion by Paul Ohm in his paper Broken Promises of Privacy: Responding to the Surprising Failure of Anonymization.

Put plans in place now, that will make next year easier. No manure required.

Last night, I spoke at OWASP Ireland's meeting in Dublin about the previously discussed Software (Security) Assurance Maturity Model (SAMM).

My presentation defined what software assurance, and in particular software security assurance, are, and why they are needed for complex software quality aspects. I also discussed what a maturity model is and how SAMM fits in with other business, project management, IT and software development maturity models. Moving onto SAMM, we reviewed the structure and how it may be used in software development teams and businesses to measure the current capability, act as a benchmark and help in building out a software security assurance programme.

There's been some discussion about applying SAMM on the SAMM mailing list, but it was good to chat with other people about their experiences and ideas to help organisations build better (more secure) software. The evening continued with an interesting talk on Niall Jordan on "Evading SQL Injection Detection Through Encoding", and then off to the nearest (almost adjacent) pub for further lively discussion and debate.

Oh, and a reminder... the Ireland chapter have organised OWASP Ireland AppSec 2009 Conference on 10 September 2009. With two tracks of application security related presentations from excellent speakers, I think it's going to be well worth attending.