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.

Taking payments online? Were you strongly encouraged to implement a 3D Secure system like Verified by VISA or MasterCard SecureCode?

A new paper from University of Cambridge Computing Laboratory describes how how online card security fails. It identifies a number of security weaknesses in 3D Secure and proposes that the economics of security have driven insecure implementations (like this), that are difficult to use, in order to move the risk to cardholders.

Ross Anderson's blog post links to comments about the paper elsewhere.

Strange as it might seem, some people publish, usually unwittingly, detailed information about the structure of their databases by revealing SQL (Structured Query Language) code.

I don't mean in error messages (which should of course never be displayed to web site users):

Nor in the generated web page source code (you wouldn't do that would you?):

Nor even when it's in a URL (I won't ask):

No, what I mean is when the code is simply indexed and appears on the site's own web pages (often as search result listings), and which then sometimes subsequently picked up by Google, Bing and so on:

So what's going on here? Without more information, I can only surmise, but I think these web sites are using catalogues (pre-built registers or collections) to index the web pages. However some of the pages have static content and others are dynamically built using database queries. So the indexing tool is recording the text from the scripting language rather than what is generated "at run time" to the web site user. These scripts should not be indexed, and thus leaked, in this way; instead the static results need to be merged and ranked with appropriate links to dynamically-created pages. If I search a dictionary web site for "query", I don't want a link to a page that has this in the code, I want the actual pages that define or reference the word "query".

The danger of automated indexing, is that it can include all types of unforeseen files in its catalogue, including backup and old copies of files, unless the indexing strategy is considered carefully:

Having the SQL displayed in this manner makes it much easier for someone to compromise the data, damage the site or its users.

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?

At this time of the year, gardeners have usually seen the best of their summer displays, and thoughts turn to tidying up the garden before the winter.

The publication of a new report from the Ponemon Institute on Data Security in Development & Testing is a timely reminder that like gardens, our web site and web application development and test systems need periodic attention, otherwise they can go wild too. The report describes the findings from a survey of IT practitioners in the United Kingdom and United States on the adequacy of their policies and technologies in place to protect real data used in development and testing. The survey is included in the report, so you can compare your own organisation.

Take some time to identify how real data are being used in your development and test systems, and determine what sensitive data is being used, stored, transmitted and how it is deleted. Are you allowed to sue the data for development and testing? Check who has access to the data, from where, and what the risks are.

If you undertake some form of masking or other anonymisation technique, do read and take into account a new summary of research and discussion by Paul Ohm in his paper Broken Promises of Privacy: Responding to the Surprising Failure of Anonymization.

Put plans in place now, that will make next year easier. No manure required.

This week, the first Irish Application Security conference is being held at Trinity College, Dublin. OWASP Ireland AppSec 2009 Conference is a full-day event with two conference tracks and optional training courses on the previous day.

I am sorry not to be attending, but did at least hear Dinis Cruz's updated presentation about OunceOpen (O2), an open platform for automating application security knowledge and workflows, at the OWASP London chapter meeting last week.

This has developed considerably since I last heard Dinis speak at AppSec EU09 in May and the vision is starting to shine through. Dinis' presentation is now on the OWASP London chapter page, but I'd recommend downloading and trying the various modules from the project website and joining the mailing list. Also at last week's meeting, Dave Marsh gave a comprehensive presentation on using tokenisation surrogates to protect sensitive data. I was surprised this approach could potentially reduce the PCS DSS scope so much, with even payment card entry forms on web pages being out-of-scope. I'll need to read the justification for that.

Apart from Dublin this week, the next big application security conferences are OWASP AppSec Germany 2009 in Nuremberg, Germany on 12-13 October 2009 and OWASP AppSec 2009 in Washington, United States on 10-13 November 2009.

Bruce Schneier's blog posting this week about Security vs. Usability highlighted an essay by Prof Don Norman (of the Nielsen Norman Group) concerning When Security Gets in the Way.

It struck a chord with me since I had just been reading an article on Econsultancy.com speculating that customer's problems with 3D Secure had led to Google Checkout Dropping Payment by Maestro. You might know 3D Secure better by the scheme-specific names Verified by Visa and MasterCard SecureCode. The implementation of these schemes by banks and e-commerce merchants has been a terrible mishmash of in-line frames, pop-up windows, unbranded pages, redirects and mandatory JavaScript. Most instances have terrible usability, many raise users' security concerns and some applied the password setup and change mechanisms poorly. The article suggests merchants have found 3D Secure decreases the conversion rate. How were usability and privacy concerns addressed during each system's design? After all, the users are the banks' customers, and the credit card companies' customers and the e-tailers' customers.

Prof Norman finishes with:

Perfect.

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.

The design and architecture of web sites and the supporting application software and systems is an important step in a well-managed development programme.

Design reviews can be used to identify security-related problems with the fundamental structure (architecture) which no amount of secure coding will solve. And, it's not just about adding network and application firewalls and intrusion protection systems (IDS)—in many cases a better (less complex, more robust) design can be achieved by considering security issues such as authentication, authorisation and integrity, and the privacy issues of data subjects themselves.

Even if you, or your development agency, don't have a formal process, you should try to build reviews into the project's requirements and ensure that software designs, architecture and data flow diagrams are itemised deliverables that require sign-off. Then any changes to these should be re-assessed, agreed and approved.

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.