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.

The review of safety at BP's Texas Refinery following investigation and report on the explosion in 2005 which killed 15 people, injured 180 and caused substantial property damage, included a recommendation to use pre-startup safety reviews (PSSRs).

We can all learn lessons from unfortunate incidents like this in other disciplines (e.g. also the sinking of the MV Herald of Free Enterprise in 1987). Do web site developers and designers have an equivalent pre-launch security review (PLSR)?

I remember once reading an email press release about a new web site, only to visit it and find out that within a few link clicks you ended up in some sort of CMS admin area; we stopped browsing immediately and contacted the site's owner. In the past I have also been asked to make a web site live on Friday afternoon at 4pm; the answer has to be "no".

What should a PLSR include for a new or revised web site? If you don't already have a security policy, standards and procedures, here is a checklist of suggestions:

Not all these checks will be needed for your project but the order in which they are done is important. For a small web site with little functionality, this doesn't have to be complicated. For example, the build documentation and disaster recovery plan could mean having a full set of source files (pages, scripts, images, etc), each night's full backup of any changing data (e.g. database and generated files), login credentials, some notes on the server's configuration and contact details for the domain name registrar, design agency and hosting company.

For any project, try to discuss launch as early as possible in its lifecycle—preferably at the bidding/tender stage, but if not, immediately on project initiation. Define the launch/release criteria well in advance. Find out what the client and project owner's expectations are and who will be responsible for what. A good launch takes time, so make sure the team have enough time to complete the launch and subsequent checks without it running into abnormal hours of the day. Your web site project's failings might not lead to people's deaths, but that doesn't mean sloppy configuration, launch and operation are acceptable. What standards do you have?

Please let me know if you think anything should be added to or altered in this launch checklist.

PS if you are looking for a launch checklist that addresses wider website issues, I'd recommend the The Ultimate Website Launch Checklist.

Today I thought I'd share some of my favourite blog posts about building software securely by implementing web application security programmes.

The excellent blog posts about building a software security assurance programme are:

• Rafal Los on Enterprise Web Application Security and Building a Web Application Security Program Without a Budget
• Justin Clarke on The Fallacy of Secure Software
• Adrian Lane on Agile Development and Security

Can you recommend any others?

As a reminder, the main software security maturity models and process models are:

• Building Security In Maturity Model (BSIMM)
• Microsoft Security Development Lifecycle (SDL)
• National Institute of Standards and Technology (NIST) SP 800-64 Rev2 Security Considerations in the Information System Development Life Cycle
• Software Assurance Maturity Model (SAMM)

Last week Microsoft also released a short document describing how to implement a simplified version of their SDL.

Which should you choose? It's what works in your own organisation that matters. Ask your software suppliers (e.g. web developers) what they use before you buy.

The next Open Web Application Security Project (OWASP) London meeting is this week.

The London chapter meeting is on Thursday 14 January 2010 in EC1. Everyone is welcome, but you need to register first (free).

There will be talks on Top Ten Deployment Mistakes That Render SSL Useless by Ivan Ristić and Using Selenium to Hold State for Web Application Penetration Testing by Yiannis Pavlosoglou, who recently joined the OWASP Global Industry Committee.

Unfortunately I am unable to attend the meeting but hope to read the presentations afterwards.

The web browser (user agent) normally sends a string of text to identify itself, but this can be blank or many other things, and can be altered by users.

The Bots vs Browsers (robots versus web browsers) web site monitors the user agent identification strings and helpfully provides access to their valuable data. They have identified over 400,000 different user agent strings to date. You can see 5,000 unidentified that are not obviously any particular search engine robot or browser and could be accidental, mischievous or malicious.

Always treat user agent strings as untrusted, and check their length and content before using the sanitised text to display, or in decision-making logic or when writing it to a file or database. The lists for particular types of devices (e.g. the iPhone) may be useful to remind you of the range of values sent. User agent strings certainly shouldn't be used for any form of user authentication.

Web sites are being published "in the cloud", but what are the cloud computing security risks?

I have mentioned previously the excellent Cloud Computing Benefits, Risks and Recommendations from ENISA. Yesterday the Cloud Security Alliance (CSA) published their updated document Security Guidance for Critical Areas of Focus in Cloud Computing V2.1 (December 2009), which was previewed at last month's OWASP AppSec DC 2009.

The operational domain (the term used for a category in this guidance document) of Application Security will be of most interest to web folk, but the remaining architectural, operational and governance domains provide full coverage of the cloud computing risks. After all, there's no point securing your web application if the server's wide open to abuse, or you don't have the clear responsibilities defined, or you don't have access to the data in the event of a disaster.

The recent Amazon EC2 Botnet is a timely reminder of the issues that can occur.

In April I described some issues with Web Application Security in the Cloud - Part 1 and in Part 2. The CSA's Domain 10 (Application Security) describes five aspects to consider:

• application security architecture
• software development life cycle (SDLC)
• compliance
• tools and services
• vulnerabilities

and provides a number of key security recommendations. The same pattern is used for the other domains.

Alternatively, if you are looking for a broader introduction to the subject, I'd recommend the book Cloud Application Architectures by George Reese and published by O'Reilly (ISBN 978-0-596-15636-7). This also has a chapter about security, but the ENISA and CSA documents provide much wider coverage and greater detail.

As I prepare to go to OWASP BeNeLux Day 2009 tomorrow to speak about compliance driven vulnerabilities in web applications, the aspect of auditability came to mind.

Audit logs record user-initiated activity (human or otherwise) in a system or application. They are a trail to establish accountability and responsibility for processed transactions i.e. what, when, where and who. Some form of audit trail is often specified in a web site's requirements, but this is often incorrectly seen as independent to other requirements. All software test cases should also identify the expected audit trail outputs and check they are being generated correctly:

• It is not sufficient for the user functionality to match the requirements alone.
• The generated audit trail must match the tests undertaken.
• It must be possible to determine the original actions from the audit trail.
• Mis-use cases should generate appropriate trails as well.

In-built audit hooks (embedding code in applications for the examination of selected transactions) and continuous auditing (near real-time auditing logic) must not introduce their own vulnerabilities:

• The extra complexity of audit code in an application requires additional security verification.
• Identify the trust boundaries around these parts of the application.
• Ensure the audit code cannot be used by malicious users to circumvent other controls such as authentication and authorisation.

Test cases will also need to be prepared to verify the protection and management of the audit trail. Ensure the integrity of the audit trail:

• The trail must be protected from subsequent modification (alteration and deletion).
• Even if the amount of logging is configurable, the default should provide sufficient detail for the business's needs.
• It should not be possible to completely inactivate all audit trail generation.

NIST have a useful document SP 800-92 on management of security logs—many of the considerations are similar for the protection of audit trails.

The extraction and examination of audit trail data must be controlled:

• Audit trails may contain personal and other sensitive information.
• The data may give away information regarding the application's code and logic.
• Consider whether parts of the data may need to be excluded, masked or encrypted.
• The privileges to read audit trails should be restricted and reviewed periodically.
• All access to the audit trail must be recorded and monitored by a separate manager.
• Audit trail data must not be destroyed before the duration of its required data retention period, and not kept beyond this time.

Remember that in some jurisdictions, capture of any personal data or monitoring of employees may need particular approval and safeguards, and some data may not be allowed to be stored at all. Happy verification!

After yesterday's long day (Thursday) at Open Web Application Security Project (OWASP) AppSec DC 2009, the second day (Friday) began promptly again at the Washington Conference Centre.

The second day had four different streams:

• Process
• Attack and defend
• Metrics
• Compliance

My own programme comprised:

• The Big Picture: Web Risks and Assessments Beyond Scanning, Matt Fisher
  A description of why automated security scanner are not sufficient to cover an entire application or detect most vulnerabilities.
• SCAP: Automating Our Way Out Of the Vulnerability Wheel of Pain, Ed Bellis
  A description of how SCAP standards can be used to combine various vulnerability feed data into a single organisation-wide repository that can be used to normalise and correlate data.
• OWASP Top 10 2010, Dave Whichers
  First look at RC1 of the new OWASP Top 10, planned for release in early 2010.
• The 10 Leasr-Likely and Most Dangerous People on the Internet, Robert Hansen
  Key people/roles in named organisations who, if compromised, could have significant adverse effect on the secure operation of the internet.
• Deploying Secure Web Applications with OWASP Resources, Sebastien Deleersnyder and Fabio Cerullo
  Case studies in the education, financial and telecommunication sectors.
• Injectable Exploits: Two New Tools for Pwning Web Apps, Frank DiMaggio
  Two new utilities to assist with injection and fingerprinting and a brief introduction to the Samurai web testing framework.
• Techniques in Attacking and Defending XML/Web Services, Jason Macy and Mamoon Yunus
  A description of three types of attack and methods to defend against them.

The presentations will be available on the conference web site.

At the end of the day, prizes for the capture the flag event were given out, vendor draws undertaken and a selection of prizes given to OWASP members who were present, selected at random.

It was a well organised event and the conference team and helpers deserved the praise and thanks.

Following an encouraging discussion of the Building Security In initiative of the US Department of Homeland Security by Joe Jarzombek, Director for Software Assurance in the National Cyber Security Division, and a short presentation from the Open Web Application Security Project (OWASP) board, OWASP AppSec DC 2009 got underway.

The conference had four streams on the first day:

• OWASP
• Tools
• Web 2.0
• SDLC

This made choosing which presentations to attend difficult, but I settled on:

• Understanding the Implications of Cloud Computing on Application Security, Dennis Hurst.
  Briefing on the upcoming second version of the guidance document from the Cloud Security Alliance.
• Transparent Proxy Abuse, Robert Auger
  The lifecycle, explanation and demonstration of an unexpected weakness in transparent proxies.
• OWASP ModSecurity Core Rule Set Project, Ryan Barnett
  Briefing on ModSecurity web application firewall (WAF) and the changes in the recently issued v2 rule set which is now an OWASP Project.
• Defend Yourself: Integrating Real Time Defenses into Online Applications, Michael Coates
  An update on the OWASP AppSensor Project and two example implementations demonstrating how the AppSensor responds to an automated scanner, and how it could suppress application worm propagation.
• The ESAPI Web Application Firewall, Arshan Dabirsiaghi
  Demonstration of code built upon the OWASP ESAPI Project to apply virtual patches to an application built in Java.
• Attacking WCF Web Services, Brian Holyfield
  Description of .NET core communications framework and how messages can be intercepted, decoded and modified.
• When Web 2.0 Attacks – Understanding Security Implications of Highly Interactive Technologies, Rafal Los
  Issues and examples of how Web 2.0 is reinventing old faults.

The presentations will be available on the conference web site.

The day ended with a generously sponsored reception for delegates to network further and practice penetration testing.

Update 14th November 2009: Part 2 added.

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.