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.

Last month I described the ability to track users sessions with browser data. A recent posting on IT Law in Ireland highlighted a series of blog posts elsewhere that give further insight into what is possible.

Well, I just got round to reading them properly. The posts on Freedom to Tinker by David Robinson and Harlan Yu are:

• Identifying John Doe: It might be easier than you think
• What Third Parties Know About John Doe
• The Traceability of an Anonymous Online Comment

The conclusion? It is possible to trace and identify individuals easier than you may think. We are dropping evidence like dead skin cells as we traverse the internet. Fact or fiction? Well the US Defense Advanced Research Projects Agency (DARPA) are taking it seriously with a recent call for research into cyber genetics, cyber anthropology and cyber physiology in its Cyber Genome Program. DARPA hopes to develop advanced methods to fingerprint or identify the origins of a cyber attacks by examining digital artifacts, and presumably other criminal activities utilising computer technology.

Getting a bit more down to earth, web site owners need to consider what information is being gathered and why, ensure this is legal, check that consent is implied or has been explicitly given for the purposes and what monitoring and analysis is performed on the data. It could be easy for system developers to carried away with tracking and tagging. Contracts with third parties should state clearly what the expectations are about the security and privacy of information, to protect web site users (employees, customers, clients, citizens) and the business.

This weekend the clocks change as we revert from British Summer Time (BST) to Greenwich Mean Time (GMT) at 02:00 BST on Sunday 25 October 2009 and the clocks go back, giving an extra hour.

What does this mean for web site security? Does running 01:00 to 02:00 twice matter? Well some brave web application owners will be disabling their systems like this online bank:

And, I don't think it's just being done as a finale to the current Energy Saving Week. Most people, quite rightly, won't be taking this rather severe step. Another millennium bug anyone? The date/time should be considered rather like other untrusted user input. Most problems will probably fall into the "business logic" category such as:

• Failure of time-based logic where dates are being compared.
• Assumptions of uniqueness in time-stamped output (e.g. by a single-threaded process).
• Running tasks again leading to possible:
  • loss of data due to overwriting
  • duplication of exports or emails
  • creation of inaccuracies in management information.
• Chronological ordering anomalies leading to other faults.

It's not just banks and other financial organisations that may have difficulties.

The time change may expose some other vulnerabilities that only exist at changeover time and/or during the next overlap hour.

• Circumvention of brute force attacks on user authentication mechanisms.
• Increased risk due to extension of a session's validity where local time is recorded.
• Failure in data validation routines for time-related comparisons.
• Incubated vulnerabilities where a time-related aspect causes the attack to be possible.
• Denial of service due to extension of account lock-out.
• Using time as a loop counter.
• Additional errors caused by any of the above leading to information leakage.

Recording the offset of local time to GMT/UTC and synchronisation should certainly be done, but may not resolve the time overlap issues. The effects on long-running "saga" requests might be especially difficult to determine. Time dependencies need to be specified and considered through the development lifecycle. Perhaps the bank is right after all?

Earlier this year, the Center for Internet Security (CIS) published Consensus Security Metrics to allow organisations to collect, analyse and share data on security performance and outcomes. These are based on the consensus viewpoint of 100 experts.

I've just had a chance to read the whole document and I'm impressed. The document includes twenty consensus metrics definitions for six business functions:

• Incident management
• Vulnerability management
• Patch management
• Application security
• Configuration management
• Financial metrics

Additional metrics for these and other business functions are in development.

The metrics are an excellent reference document and are carefully explained, referenced and excellently presented. These should be of interest to people owning, operating or developing web applications and looking for measures to examine performance, regardless of their role or experience. If you are looking for some metrics, don't re-invent the wheel, read this document first.

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.

A recent proposed revision of the policy on web tracking technologies for US federal web sites by the Office of Management and Budget set out four principles regarding user analytics and tracking.

• Adhere to all existing laws and policies (including those designed to protect privacy) governing the collection, use, retention, and safeguarding of any data gathered from users.
• Post clear and conspicuous notice on the website of the use of web tracking technologies.
• Provide a clear and understandable means for a user to opt-out of being tracked.
• Not discriminate against those users who decide to opt-out, in terms of their access to information.

The document recommends avoiding outsourced tracking and outsourced data analysis—issues not thought about by many organisations. Just because a third-party service is cheap, doesn't necessarily mean it's the appropriate method to use. I'm less convinced about the example of using cookies to record opt-outs.

The proposed revision attracted a well-considered joint response from the Center for Democracy & Technology and the Electronic Frontier Foundation. They suggested three additional principles.

• Limit use of tracking data.
• Limit retention of tracking data.
• Obtain third-party verification.

The response also referenced their May 2009 Open Recommendations for the Use of Web Measurement Tools on Federal Government Web Sites which recommended the following:

• Use data only for measurement.
• Prominently disclose.
• Offer choice.
• Limit data retention.
• Limit cross-session measurement.
• Obtain third-party verification.

Whilst none of the final guidelines will be mandatory outside the US federal sector, the issues raised are worth consideration by all commercial and non-commercial web sites. For example, the recommendations and principles above could be used to help guide a privacy impact assessment of an organisation's own use of web analytics and tracking technologies.

Privacy Notices Codes of Practice is being launched today by Richard Thomas, the Information Commissioner.

Apart from the minor concern that Richard Thomas had included his signature in the document, the draft looked like it would be a very useful code of practice for most small-to-medium organisations including local government and professional organisations. One issue I raised at the time was the potential for aggregation of data to have more meaning than the individual parts, and that this should be considered in privacy notices so that users are aware of any potential problems. Some of the web form examples included didn't necessarily include other (non-privacy related) good practice such as for web accessibility and web usability. There was also some lack of clarity over the use of the word "security", e.g. "Security and Privacy Statement", which I hope has been corrected.

The explanation of fairness, and good and bad examples paper and web form layouts in the draft from the Information Commissioner's Office (ICO) were particularly helpful.

I'm looking forward to seeing the final version.

Update 10:30 hrs 12th June 2009: The ICO has published a press release and the final Privacy Notices Code of Practice.

Update 14:20 hrs 12th June 2009: The final version has incorporated over 60 suggestions as a result of the public consultation, including the issues of aggregation and use of the word "security". Watch out for legislation relating to Assessment Notices and dealing with failures to act on Assessment Notices.

Never spy on your web site visitors. Users of your web site/application will not appreciate it. It may also be illegal.

The story in the Times newspaper concerning Council Uses Terror Law to Spy on Shirker in Shower reminded me how easy it is to get carried away with inappropriate monitoring and analysis.

Like employment contracts for staff, make sure your web site privacy policy defines what data you collect, and for what purposes. Don't be tempted to mine this data for other purposes (e.g. marketing) especially if it includes personally identifiable information and users have not opted in for this use.

Check who and what has access to web site and web application logs and audit trails, including archives and back-ups. People with access need to be trained how to handle such data appropriately, for what purposes and to ensure they do not violate laws.

This data should also be subject to an agreed data retention and disposal policy.

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.

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.