It's encouraging to see commercial information security organisations sharing their experience, knowledge and data, such as in the OWASP Security Spending Benchmarks Project. Last week Verizon also published details of its Incident Sharing Framework.

The framework (beta, 1st March 2010) is used in Verizon's internal security metrics gathering processes and to produce its public data breach investigation reports. The framework provides details of how various security incidents should be classified and recorded, including what is done to remedy the situation and further actions taken, such as education. By publishing the framework, Verizon hope that other organisations might collect similar data and ultimately share it to improve common knowledge.

Some other related frameworks and initiatives are listed at:

• Security Content Automation Protocol (SCAP), NIST, specifications and emerging specifications
• Consensus Information Security Metrics, CIS (see previous post on Web Application Security Metrics

These frameworks may be too complex to consider for some organisations, but even so, they provide a good guide to the kind of things you should be considering in security and privacy incident management policies and procedures. They are also useful standalone references for classifying various types of attacks and accidents.

The Ponemon Institute has realeased its latest survey of UK data losses.

The findings of the 2009 Annual Study: Cost of a UK Data Breach indicate that personal data losses ("breaches") are still increasing in cost (per record). The report discusses the growth of data breaches due to malicious attacks and botnets, how prevalent these are compared with other losses and the relative costs. The report also presents comparitive data for losses involving third parties, and for organisations who have experienced their first data loss.

Although we hear a lot about lost or stolen devices (laptops, USB sticks, mobile phones, etc) and malicious/criminal attacks, the most common primary cause for the losses was negligence.

The recent news that the German government is considering buying stolen personal data of its citizens who it suspects of tax evasion is worrying. This sort of activity may fuel personal data theft by leavers and disgruntled employees.

The report is available in PDF format.

Well, we hope not. On Saturday morning, the train I was travelling on from London to Newcastle was slightly delayed due to the imposition of speed limits caused by high winds. As we began to pull out from Darlington Station, there was a shudder and we stopped. It seems we had been shunted from behind by a smaller Northern Rail train.

I think there were some minor injuries to some passengers on the Northern Rail train, but as far as I could tell the larger National Express East Coast train only suffered from being withdrawn from service. I must say I felt surprise that minor train accidents still occur—we are aware of serious incidents "wrecks", such as the Paddington rail crash 10 years ago, but we don't hear much about defects and minor accidents. These must be occurring too and are not necessarily rare events.

So perhaps it's similar for web site security? Whilst the vast majority of web application security incidents won't lead to loss of life, we should expect to see smaller problems and minor incidents, not just the larger breaches and losses. If you only see the train wrecks, then I suspect there isn't enough monitoring and reporting. I don't have any further data regarding this, but will do some research.

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.

It can be hard to justify business spending when web sites are often viewed as low-value assets. The fact that so much Internet content and services are free, and you can buy a web site for less than the cost of a colour TV licence in the UK reinforces this idea in many small and medium enterprises (SMEs).

Much of my work is related to dealing with security incidents, such as web sites which have been hacked, or where an organisation is having security requirements imposed by their own customers and clients. Often these activities are undertaken late in the project and are therefore less effective, and more costly, than they might need to be.

I adhere to the principle "prevention is better than cure", and encourage the early consideration of security and privacy matters—just like any other business process requirement. It was encouraging to read the useful guidance and pointers on Business Cases For Software Security Initiatives but for many organisations, the issues are too complex and they don't have any supporting data. For those I recommend, as a starting point, concentrating on four types of issue:

1. mandatory compliance issues (e.g. legislative and contractual)
2. problems which can assist theft or fraud
3. security events which would be severely disruptive and possibly put the organisation out of business
4. issues for customer trust and ongoing reputation

It's always organisation specific though. As organisations mature, they can be encouraged to look at wider security issues—but, let's get the basics right first.

An econsultancy.com blog posting concerning search engine optimisation (SEO) and website security caught my eye. Website security as SEO discusses how compromise of your web site or web server might lead to it hosting malware and the disastrous, and rapid, decline in search engine referrals.

The discussion references What's An Exploit Worth To Your Google Traffic? which explains the experience of CenterNetworks, a collection of sites helping various industry professionals learn more about topics such as social networking, Web 2.0 and social media. Following a compromise that left malware being served to visitors from their site, traffic was reduced significantly:

Here's what Google might display after a potential customer clicks on your natural search link, for a web site I almost visited this week:

With one web page being infected every 4.5 seconds by a new malware attack (New Web-Based Malware Attack Hits Internet with Huge Rate of Infections, 15 May 2009), it is legitimate web sites that are spreading the problem (Legitimate Websites are Hosting Most of the Web-Based Malware Due to Poor Security Measures, 15 May 2009).

Many organisations spend a significant amount on search engine optimization (UK Search Engine Marketing Benchmark Report, April 2009)—a single vulnerability could throw much of that investment away. I have three recommendations:

• think about what you would have to do if the same situation occurred to your web site
• get your web site tested for vulnerabilities that could be exploited to host malware
• make sure you have ways to detect the situation, if it arises, as soon as possible.

And, do them now.

The most successful phishing scams include the construction of a virtually identical website to the targeted organisation. Most of the content is usually cloned from the original legitimate website. A recent paper discusses measures that can be taken to help identify the source of the cloned content for fraud investigations.

Companies with well-known brands have always had to battle to maintain their trademarks and brands in the physical world. Here's a takeaway shop using the London Underground logo:

But what about the online world? How do you identify the person who stole your assets including designs and content? Farmers have been long-term users of tagging and tattooing to track animal movements, record health information or even to help find the mother for a lost lamb at this time of the year.

There are even proposals to use electronic ID tags for sheep. But web application content can't be tagged physically in the same way.

Gunter Ollman's paper Anti-Fraud Image Solutions reviews the subject, outlines and compares the techniques and limitations of adding traceable markers to web application content. These include steganography, watermarking, image meta data, mosaic layouts, semagrams, file names and hidden graphics. If you are lucky, the marker will be identifiable in the cloned phishing site, giving information on the possible source.

Gunter reminds us that no technique is infallible and the identification of the source of the cloned site by no means indicates the true perpetrator.

This type of tracing may also be useful for marking non-production, archived or backup web application source code and media, to assist with leak source identification. In this scenario, the thief (or accident-prone employee) does not necessarily have the goal of reproducing the original website and therefore the perpetrators may not be looking for hidden tracers to remove.

In Web Application Security in the Cloud Part 1, I mentioned some risks associated with "cloud computing", and other services provided online by third parties.

At my work, we sometimes use Infrastructure as a Service (IaaS) virtual hosting to undertake testing. These are not a business critical use and there is never any client, or business, data on the servers. One of these is GoGrid. A few weeks ago it seems their services were offline for an extended period (significant if the service is a vital process), due to a combination of denial of service (DoS) attack and scheduled maintenance, culminating in this Update from GoGrid Founders:

I applaud the efforts undertaken by service providers such as these, rather than being unable to recover like Ma.gnolia after a, much less complex, database and backup loss:

The video on the Ma.gnolia home page is worth watching before signing contracts with third party providers.

For further discussion of the issues, some further blog posts which I recommend, are:

• The Cloud: policy consequences for privacy when data no longer has a clear location
• Cloud Catastrophes (Cloudtastophes?) Caused by Clueless Caretakers?
• The Vagaries Of Cloudcabulary: Why Public, Private, Internal & External Definitions Don't Work...
• The new cloud infrastructure: Do you care?
• Does Cloud Infrastructure Matter? You Bet Your Ass(ets) It Does!

Look before you leap!

Update 27th November 2009: See also Cloud Computing Risks.

What a pity. Six weeks on and Sage Live, a new on demand Software as a Service (SaaS) web product from business management software providers Sage Group plc, is still offline. It was withdrawn at the end of January after less than a month of operation due to serious security flaws.

An article on ZDnet Sage Shows Why Bigcos Can't be Trusted with SaaS, describes the events leading up to the event which followed the blog posting on Sage Live - Serious SaaS Security Issues by a competitor KashFlow who Sage had previously complained about to Trading Standards. Despite 18 months in development, it took users of the public beta version to identify basic security flaws in Sage Live that have since been confirmed by more expert reviewers.

Developing web applications is not the same as developing conventional software, and Sage got it badly wrong. At least they have taken it offline—but it will take a lot of effort to rebuild the required trust in the service if it re-launches.

In How Much Logging, Monitoring and Alerting? I suggested logging implementations are often incorrect for most web sites and web applications.

The logging should be defined in terms of its intended use. We're talking here specifically about information security, so what might the uses and logging be?

1. To confirm data and process integrity and availability:
   • completeness and consistency
   • response times
   • function/process abandonment
   • session timeout
   • up-time
   • data changes
   • data mirroring, back-ups and archiving
2. To identify and provide enough information for investigation of:
   • errors and unexpected conditions
     • code errors
     • database access and performance
     • web server errors
     • third party services
     • lack of storage space
   • data breaches
   • use and mis-use
     • authentication successes and failures
     • access (authorisation) failures
     • excessive use
     • data validation failures
     • fraud and other criminal activities
     • suspicious, unacceptable or unexpected behaviour
   • modifications to configuration
   • security reports from users and third parties
3. To provide data:
   • subject access requests
   • freedom of information requests
   • litigation document requests
   • police and other regulatory investigations
4. To monitor content changes:
   • database fields
   • file contents
   • generated web page content
5. To demonstrate compliance:
   • internal policies and standards (e.g. information security policy, quality standards)
   • contractual obligations (e.g. PCI DSS)
   • change control
   • use of other's intellectual property
   • legislation (e.g. Data Protection Act)
   • regulation (e.g. Financial Services Authority)
   • external standards (e.g. Web Content Accessibility Guidelines [WCAG] 2.0 conformance claim)

It's important the logging is centralised so that alerts and reporting can be drawn from across all sources (web, application, file and database servers, network devices, etc). The scope and extent of logging ought to be be determined by business needs and the threats. For a typical e-retail site, the payment, check-out and any registration facilities will require greater logging than other parts. In some cases it may be appropriate to set particular thresholds for additional logging (e.g. transactions above a certain value, requests from particular clients, users in some geographic locations). This is easier if the requirements can be built into projects at an early stage.

The logging then needs to be tied in with appropriate monitoring, alerting and reporting. If you want alerts raised automatically, you'll have to think of what conditions initiate these. Referring back to specifications, threat models and test cases can be of use with this.