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?

Security and audit logging should be defined, implemented and tested for every web application. But what about log management and analysis?

This week Raffael Marty posted an updated item to his blog about a Maturity Scale for Log Management and Analysis. It is an excellent review.

Whilst much of this management and analysis is intended to be external to an application, we need to remember each application needs to record adequate information to feed into these analysis and reporting tools. And why do that? Read the bullet points under return on investment (ROI) at the end of the article. What else? Well perhaps also:

• feedback into the development lifecycle (to improve subsequent patches, versions and other projects)
• greater trust by users
• brand protection
• protection of information assets (not just preventing leaks, but ensuring accuracy and integrity).

Therefore, build adequate logging in from the start. Web server logs are not enough!

An article about the upcoming new regime for the classification and labelling of chemicals reminded me to write about software assurance (i.e. software security) labelling (and since web sites are software). From 1 December 2010, the UN Globally Harmonized System of Classification and Labelling of Chemicals (GHS) comes into force, implemented in Europe by the Regulation (EC) No 1272/2008 of the European Parliament and of the Council of 16 December 2008 on classification, labelling and packaging of substances and mixtures (CLP), amending and repealing Directives 67/548/EEC and 1999/45/EC, and amending Regulation (EC) No 1907/2006.

CLP implications and guidelines are explained by the UK Health and Safety Executive (HSE) but are defined fully in the UN's documentation. The headline chemical labelling indicates the potential damage/harm that can occur, rather than the content/properties of the agent. I like this "impact" approach. Nutritional labelling on the other hand generally tends to focus on ingredients and their properties, but some food labelling is also beginning to attempt to classify low/medium/high fat/saturates/sugars/salt levels, which is more akin to the impact approach.

Jeff Williams (CEO of Aspect Security and Chair of OWASP Foundation) proposed a Software Facts label five years ago at OWASP Appsec Europe. This would be similar to appliance energy usage labels, food nutrition facts label, material safety data sheets or laser safety classes. That idea was taken up by NIST and the Software Assurance Consortium (SwAC) to develop another proposal.

Comment here and here around the same time in 2005 describes some of the challenges. Indeed many more aspects of the software development lifecycle impact upon the creation of secure software. But simplicity is needed in the presentation of such information—perhaps some high-level impact related indicators augmented by the more detailed information for different audiences (e.g. users, operators, administrators, system achitects). SwAC's version seems to be somewhat aimed at software development teams, instead of people in end user organisations, especially those involved with procurement decisions. Whilst some people will want to know the data behind a classification, most businesses and consumers will need something more akin to the CLP headline labels relating to business (or personal) impact as a starting point for their decisions.

• How dangerous is this software?
• How reliable is it?
• How does it affect privacy?
• How does the IT environment affect these?
• How are these affected by changing the default settings?

This a big challenge. Just specifying the privacy practices for a web site can be complex. ENISA's Common Assurance Maturity Model (CAMM) project is trying to define how cloud service providers can be compared to allow users to make informed decisions about the risks. Perhaps that project will develop into some form of labelling scheme, or at least provide ways for typical consumers of the services to determine their own risks as simply as possible.

I don't know the status of the SwAC project but will now make the effort to find out.

Last week, Symantec published its latest Internet Security Threat Report.

The 95-page report describes Symantec's methodology, findings and recommendations about internet security threats to businesses and individuals. It describes the financial and other losses possible such as damage to reputation and data theft. There is a strong focus on protecting confidentiality and less about how internet threats affect the integrity of data and availability of information systems and business processes.

In the two chapters on Vulnerabilities and Malicious Code Trends, the importance of publicly accessible services (web, mail and FTP) and vulnerabilities in web browsers and web browser plugins in the malware ecosystem are highlighted and recommendations for protecting these servers are provided. The top Web-based attack in 2009 was associated with malicious PDF activity, which accounted for 49 percent of the total.

The chapter on Phishing, Underground Economy Servers, and Spam Trends provides a good insight into how your users may be targetted by third parties hoping to lure them into visiting other web sites. the report makes the important point that "the use of brand(s) in phishing activity can significantly undermine consumer confidence in its reputation". The financial sector continues to be the primary target for phishing attacks, but all types of organisation can be targetted.

Appendix A describes some best practices that businesses (enterprises) and consumers should follow to reduce the risk from internet threats. Many of these relate to using electronic mail and browsing web sites. The slightly more web application related recommendations include employ defense-in-depth strategies, administrators should limit privileges on systems for users, turn off and remove services that are not needed for normal company network operations, test security regularly to ensure that adequate controls are in place, educate management on security budgeting needs, administrators should update antivirus definitions regularly, always keep patch levels up to date, enforce an effective password policy and ensure that emergency response procedures are in place.

A shorter executive summary of the report is also available.

On Wednesday I attended the Information Commissioner's Office (ICO) Personal Information Online Conference 2009 at which the ICO launched their consultation on the new Personal Information Online Code of Practice.

Manchester and Salford gave us a beautiful sunny day for the event which briefed delegates on the ICO's approach to data protection and an outline of the collaborative process used to develop the draft code of practice. Iain Bourne, Head of Data Protection projects, noted that fewer than hoped public sector organisations had been involved to date, and they would like more feedback from this sector in particular during the consultation phase that ends on 5 March 2009.

My first impressions are this will be a useful document for organisations without staff dedicated to data protection or compliance, especially once the examples and SME checklist are added. The structure and content are still a little raw, but probably about right for the start of a 12-week consultation process. Areas where I am already considering providing feedback are:

• local storage of personal information (not just cookies)
• verification of protection
• suppliers, sub-contractors and staff
• monitoring and anomaly detection
• transmission of personal information
• inclusion of third party content in web sites
• using cookies to enforce an opt out
• additional reference materials.

The full text and consultation document is available as a PDF.

Feedback on the Personal Information Online Code of Practice can be provided using the ICO's consultation portal with further background available in the related press release.

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.

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.

Last week I discussed the business case for web security and how this is necessarily organisation-specific.

If you use common IT investment models, you may want to look at the paper Business Models for Assurance on the US Build Security In (BSI) web site. But what are real organisations spending?

Sources of data to compare yourself with are very rare and it's good to see the second quarterly report on Web Application Security Spending Benchmarks. This quarter, the report has a special emphasis on three aspects of cloud computing:

• Infrastructure-as-a-Service (IaaS)
• Platform-as-a-Service (PaaS)
• Software-as-a-Service (SaaS)

This type of benchmarking is really useful. Years ago, I helped with some work on benchmarking water usage across UK industry sectors—without this type of initiative it is difficult to determine whether what you are doing is reasonable.

Old, backup, "secret" and test pages, scripts and other files shouldn't be left on live web sites. The Visit Britain web site should be a showcase for Britain, but I was trying to find a particular page and looked at their 97-page long full sitemap.

Oops, the 4th, 6th, 7th and 8th links were all test or old pages. I couldn't believe this prominent web site didn't have procedures in place to manage draft and test content, or even that they were making such pages live on their web site. The result test-script worried me most but fortunately all four of these returned were not found when clicked.

I wonder what the page "Delete" does though?

People use search engines such as Google to find hidden information on website (aka Google Hacking), but it's uncommon for web sites to clearly list it on their own site map. Rather than ploughing my way through the impenetrable site map, I switched to Google to see what it had found using the search query "site:www.visitbritain.co.uk test". Skipping the results about cricket test matches and testing your handicap, revealed more links to more test pages:

My favourite must be the page with the parent page labelled "Food & Drink - to be deleted EVENTUALLY" in the breadcrumb trail:

These types of practices don't instill any confidence in the management of the web site. Old, backup and test files may contain sensitive data, allow access to the application or functions otherwise restricted, or contain faults that have been fixed in the current version. And, if you actually list them, it looks terrible! Web sites and web applications, don't just look after themselves—you need clear policies, a well-designed specification, a robust development contract, good management, skilled staff, verification processes and be willing to learn from good practices elsewhere.

Today's message: read Testing for Old, Backup and Unreferenced Files.

The Web Site Security Maturity Model gives an at-a-glance indicator, or litmus test, of an organisation's web site security posture!

Organisations tend to fit into one of five categories, which I'll light-heartedly call the Web Site Security Maturity Model. This is comprised of five maturity levels, and it's very easy to determine your own organisation's level. Start at the lowest (level 1) and work up the maturity model—stop as soon as you agree with the statement:

1: Use FTP to update the web site

2: Worried about web site security

3: Have undertaken a web site security audit or review

4: Security built into web site development and operation processes

5: Don't have a web site

So on this quick guide, the safest option is not to have a web site. Many small and medium-sized organisations are operating at maturity level 1.

But seriously, if you want to review and improve the security of your web site and other software development processes properly, the Software Assurance Maturity Model is the best starting point.