It seems we can't go a day without hearing something about cyber threats or cyber war in the mainstream press. But what's the reality?

The World Economic Forum (WEF) published its annual report on global risks in advance of the WEF Annual Meeting 2011 this week in Davos. Cyber security (encompassing online data and information security and critical information infrastructure breakdown) was listed as one of five "risks to watch", which "may surprise or overwhelm us" due to varying levels of confidence in the likelihood of significant impact but which "experts considered may have severe, unexpected or under appreciated consequences". The report discusses cyber theft, cyber espionage, cyber war and cyber terrorism specifically but also warns about design flaws in internet-connected smart systems. Cyber security doesn't however make it into the report's Top 10 risks by likelihood and impact combined (Table 5, page 44).

Meanwhile the Organisation for Economic Co-operation and Development (OECD) published a report Reducing Systemic Cybersecurity Risk. This is an output of the OECD Future Global Shocks project which is looking at options for governments to enhance capacity to identify, anticipate, control, contain and/or mitigate large disasters. The report is at a greater level of detail than the high-level WEF document, . The report concludes that there are very few single cyber-related events have the capacity to cause a global shock, but that governments should make detailed preparations to withstand and recover from a wide range of unwanted accidental and deliberate cyber events. Most breaches of cyber security (e.g. malware infestations, distributed denial of service, espionage, actions of criminals, recreational hackers and hacktivists) are expected to be relatively localised and short-term in impact.

Comforted? Remember that "local and short term" on a world leader's global scale might be the whole of your business or market. Assess the risks, and make decisions based on your own context.

If you want further advice on dealing with cyber security incidents, last week the European Network and Information Security Agency (ENISA) published its Good Practice Guide for Incident Management. Although it is aimed at national/governmental Computer Emergency Response Teams (CERTs), it contains good practices, practical information and guidelines for the management of network and information security incidents which are of use to a wider audience. See also the NIST Special Publications (800 Series) for more documents like this.

The construction site in Clerkenwell of the Goldsmiths' Centre for The Goldsmiths' Company has many banners draped around its perimeter including this one about zero harm:

So, not only are they stating compliance with the considerate constructors scheme, but there is a commitment to "zero harm" during development:

• zero deaths
• zero injuries to the public
• zero ruined lives among all our people.

Well, you can't complain about the objectives. The details of the zero harm vision include a target metric: "an absolute ceiling on an Accident Frequency Rate (AFR) of 0.1 by end 2012". It's a pity that all of us in software development can't have similar principles; I'm not even aware of any software trade organisations with anything like this. SAFECode is perhaps the closest thing. Nothing concrete from .UK. How about zero vulnerabilities, zero data loss and zero malware transferred to users? Surely that's easier to do than preventing deaths, injuries and ruined lives?

Perhaps not. The upcoming OWASP Summit 2011 in Portugal will be working on why we still have so many security problems in so many applications, what has been accomplished, what has & hasn't worked, what we have been doing right, what we have been doing wrong, and how to make OWASP more effective. These people have already confirmed their attendance.

Apart from contributing in the OWASP Global Industry Committee sessions, I'm hoping to widen the debate about the impacts of security defects, to the impacts on people (in addition to organisations) by thinking more about aspects such as privacy and human safety. By putting information assurance more in the context of business concerns, I hope to spread application security awareness and help governments, companies and other organisations understand the risks and methods to improve.

If you have something to contribute, please do come to the summit. Also, if you can, sponsor the summit to help pay for some others to attend. Everyone is free to participate in OWASP and all of itsmaterials are available under a free and open software licence.

Let's have an "Improving the Image of Software Development" initiative.

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?

The Interactive Advertising Bureau (IAB) and Association of American Advertising Agencies (4A's) have published a draft revised Standard Terms and Conditions for Interactive Advertising. Whilst this is principally aimed at the USA market, due to the international nature of the Internet, I thought it worth a mention here.

Use of the template (full title "Standard Terms and Conditions for Interactive Advertising for Media Buys One Year or Less") is voluntary and open to negotiation between media companies and advertisers. However it does discuss data usage and privacy. This is important if you have advertising on your own web site and need to write a privacy notice. Without knowing the agreement between the advertiser and media company, how can you inform your web site users what will happen to their personal information? Although this is only an example template, it probably contains most of the likely issues you will come across in other ones. The definitions of "user volunteered data", "performance data", "site data" and "use of collected data" probably need careful reading and advice from a lawyer! The education version provides some further explanation of terminology and the changes since the previous version.

The template also describes the "special situation of User-Generated Content (UGC) pages" on advert placement and positioning—there could be an interesting discussion if the actual content was neither that intended by the site owner, nor that added by the user, but instead was the result of some malicious injection.

There doesn't seem to be any reference to malware on the site or malware delivered by the advert.

Of course, including third party content is a risk that should be considered in itself.

In this month's PC Pro magazine, Davey Winder commented on the Information Security Awareness Forum (ISAF) concerning their recommendation to have "report abuse" links on web sites.

In his column titled "Stupid Security" in the Online Security section of Real World Computing, he says there are too many "click this" links on most sites and that a report abuse link on a fake site is likely to give you a fake answer. Very true.

But that doesn't get away from the problem that people still need to have somewhere to go to ask for help, to query account entries, to answer concerns or to report suspicious emails and web pages. That's why we have phone numbers printed on credit cards, bank statements and even on web sites.

The ISAF and its member organisations are doing more than many others, including their excellent Directors' Guides, and they didn't deserve this. Perhaps PC Pro will become a member and contribute to the effort to promote and improve information security awareness.

Blind adherence to methods without using professional judgment is commonplace across all work sectors.

Just because a system is out-of-date, not supported by the supplier or contains known security weaknesses, doesn't mean it has to be rebuilt or replaced.

An article in The Chemical Engineer April 2009, by Harvey Dearden, discusses professional judgement and reproduces the following statements from the UK Engineering Council's Code for Professional Conduct regarding risk issues:

and:

The first statement could easily be re-written replacing "hazard" and "safety" with "threat" and "security" respectively. The second is equally true for assessing application security risks. However, in security engineering we do need to be aware of the lack of good statistical data to help form valid judgements.