Gosh, it's 25th December 2012 already.

Best wishes to everyone for the winter solstice, Christmas, the new year and anything else you are celebrating. Have a good holiday.

Didn't 2011 go fast? Still a couple of days until Christmas day, but this will be my last post before then.

Season's greetings to you all. I have a couple of final posts before the end of the year, about two more documents worth reading. One is rather long and detailed...

There's an opportunity to win a free entrance ticket to the OWASP AppSec EU 2011 conference, being held at Trinity College, Dublin in June.

The draw will be taking place at tonight's OWASP London Chapter meeting here in Clerkenwell, EC1M this evening at the Charterhouse Bar — arrive from 18:30 for a 19:00 hrs start. You have to register first, and attend this evening to be eligible for the draw. There is also another prize — a copy of "Implementing SSL/TLS: Using Cryptography and PKI", supplied by Ivan Ristic on behalf of the author Joshua Davies, and a dozen smaller runners up awards. Don't miss the talk by Steve Lord about Wordpress security and a discussion about the outcomes from the recent OWASP Summit in Portugal.

Whilst on the topic of AppSec EU in Dublin, I was pleased to hear that my proposed presentation about the fantastic AppSensor Project has been accepted for a slot in the afternoon of the 9th June. As a speaker, I have now also had a snapshot interview which is available on the conference site. For my occupation, I thought "engineer" sounded better than "consultant"!

Registration is open for training (7th-8th June) and the conference (9th-10th June).

Please say hello if you make it along this evening.

Congratulations to the winners of the Computer Weekly IT Blog Awards 2010.

Graham Cluley won in the IT Security category, with runner up Countermeasures.

This Clerkendweller : Web Security, Usability and Design blog has been short-listed for the Computer Weekly IT Blog Awards 2010 in the IT Security category.

Last year I was nominated in the Individual IT Professional Male category, but I suppose the IT Security category is more relevant, even if most of my posts are aimed at web site/application owners, developers and designers rather than security folk.

Please vote for your favourite bloggers and tweeters, whoever they may be.

I arrived in Dublin three hours ago in advance of tomorrow's OWASP AppSec Ireland 2010 at Trinity College.

I've never been to a city with so many pubs, bars, convenience stores and taxis in such a small area. I've also heard it's good for application security too.

Tomorrow I will be using Twitter during #appsecireland and hopefully update my blog again in the evening.

Sometimes when I'm out socially and people ask what I do, the conversation progresses to concerns about their own web site. They may have a hobby site, run a micro-business or be a manager or director of a small and medium-sized enterprise (SME)—there's all sorts of great entrepreneurial activity going on.

It is very common for SMEs not to have much time or budget for information security, and the available information can be poor or inappropriate (ISSA-UK, under the guidance of their Director of Research David Lacey, is trying to improve this). But what can SMEs do about their web presence—and it is very unusual not to have a web site, whatever the size of business.

Last week I was asked "Is using <company> okay for taking online payments?" and then "what else should I be doing?". Remember we are discussing protection of the SME's own web site, not protecting its employees from using other sites. If I had no information about the business or any existing web security issues, this is what I recommend checking and doing before anything else:

• Obtain regular backup copies of all data that changes (e.g. databases, logs, uploaded files) and store these securely somewhere other than the host servers. This may typically be daily, but the frequency should be selected based on how often data changes and how much data the SME might be prepared to lose in the event of total server failure.
  • check backup data can read and restored periodically
  • don't forget to securely delete data from old backups when they are no longer required
• Use a network firewall in front of the web site to limit public (unauthenticated user) access to those ports necessary to access the web site. If other services are required remotely, use the firewall to limit from where (e.g. IP addresses) these can be used.
  • keep a record of the firewall configuration up-to-date
  • limit who can make changes to the firewall
• Ensure the host servers are fully patched (e.g. operating system, services, applications and supporting code), check all providers for software updates regularly and allow time for installing these.
  • remove or disable all unnecessary services and other software
  • delete old, unused and backup files from the host servers
• Identify all accounts (log in credentials) that provide server access (not just normal web page access), such as used for transferring files, accessing administrative interfaces (e.g. CMS admin, database and server management/configuration control panels) and using remote desktop. Change the passwords. Keep a record of who has access and remove accounts that are no longer required and enable logging for all access using these accounts.
  • restrict what each account can do as much as possible
  • add restrictions to the use of these accounts (e.g. limit access by IP address, require written approval for use, keep account disabled by default)
• Check that every agreement with third parties that are required to operate the web site are in the organisation's own name. These may include the registration of domain names, SSL certificates, hosting contracts, monitoring services, data feeds, affiliate marketing agreements and service providers such as for address look-up, credit checks and making online payments.
  • ensure the third parties have the organisation's official contact details, and not those of an employee or of the site's developers
  • make note of any renewal dates
• Obtain a copy of everything required for the web site including scripts, static files, configuration settings, source code, account details and encryption keys. Keep this updated with changes as they are made.
  • verify who legally owns the source code, designs, database, photographs, etc.
  • check what other licences affect the web site (e.g. use of open source and proprietary software libraries, database use limitations).

Do what you can, when you can. Once those are done, then:

• Verify the web site and all its components (e.g. web widgets and other third party code/content) does not include common web application vulnerabilities that can be exploited by attackers (e.g. SQL injection, cross-site scripting).
  • use resources such as the OWASP Top Ten and WASC Threat Classification
  • build security requirements into future developments
• Check what obligations the organisation is under to protect business and other people's data such as the Data Protection Act, guidance from regulators, trade organisation rules, agreements with customers and other contracts (e.g. PCI DSS via the acquiring bank).
  • impose security standards and obligations on suppliers and partner organisations
  • keep an eye open for changes to business processes that affect data
• Document (even just some short notes) the steps to rebuild the web site somewhere else, and to transfer all the data and business processes to the new site.
  • include configuration details and information about third-party services required
  • think about what else will need to be done if the web site is unavailable (does it matter, if so what exactly is important?)
• Provide information to the web site's users how to help protect themselves and their data.
  • point them to relevant help such as from GetSafeOnline, CardWatch and Think U Know
  • provide easy methods for them to contact the organisation if they think there is a security or privacy problem
• Monitor web site usage behaviour (e.g. click-through rate, session duration, shopping cart abandonment rate, conversion rate), performance (e.g. uptime, response times) and reputation (e.g. malware, phishing, suspicious applications, malicious links) to gather trend data and identify unusual activity.
  • web server logs are a start, but customised logging is better
  • use reputable online tools (some of which are free) to help.

That's just the basics. So, what would be next for an SME? If the web site is a significant sales/engagement channel, the organisation has multiple web sites, is in a more regulated sector or one that is targetted particularly by criminals (e.g. gaming, betting and financial), takes payments or does other electronic commerce, allows users to add their own content or processes data for someone else, the above is just the start. Those SMEs probably need to be more proactive.

This helps to protect the SME's business information, but also helps to protect the web site users and their information. After all, the users are existing and potential customers, clients and citizens.

Oh, the best response I had to someone when I was explaining my work: "You're an anti-hacker than?". Well, I suppose so, but it's not quite how I'd describe it.

Any comments or suggestions?

I have tried to post messages on every Tuesday and Friday, and this week Friday is Christmas day.

So, best wishes. Let's hope your presents are as numerous and glitzy as this shop window display in Selfridge's on Oxford Street, London.

Last night, I spent an enjoyable Christmas eve at the Holly Bush Inn here in Tarset, where there were the usual roaring fire, real ale, good conversation, and unusually a dominoes competition (I was knocked out the competition after only the second round by one of the local farmers). I'm off now for a walk across the Northumberland snow on this beautiful sunny, but cold, morning.

Have a good day yourselves.

The Clerkendweller Web Security, Usability and Design Blog, about security issues for web site designers, developers and owners, has been shortlisted for the Computer Weekly IT Blog Awards 2009.

This blog was nominated in the Individual IT Professional Male category. Please vote for your favourite bloggers in the next few days.

It came as news to me that there is a UK Risk and Regulation Advisory Council (RRAC). It has been considering how distorted perceptions of risk can encourage poor policy-making and unnecessary laws.

The RRAC's report on Response with Responsibility Policy-Making for Public Risk in the 21st Century includes some useful discussion and ideas on the perception of risk. I think there are many parallels with information security risk such as the un-necessary spreading of Fear, Uncertainty and Doubt and risk perception & risk-reduction behaviour in The Psychology of Security.

Information privacy and security professionals would do well to read the case study on "Tree Safety – The Role of the Risk Actor" on page 15 of the RRAC report which discussed a proposal for tree safety management and a lack of participtaion during the consultation stages except for arboriculturalists ("tree consultants").

The privacy and security industry need to make sure, we don't blindly recommend the ALARP principle (As Low As is Reasonably Practical), or be seen as promoting our own vested interests, whether by being a product vendor or provider of consultancy services. Yes, risks should be kept as low as reasonably practicable, but they need to be considered in the context of the individuals, the business and society.