Designers of web sites and web application systems have many places where potential attacks could be detected. But where should attacks be stopped?

There is of course the problem of identifying what is exactly an attack—is it a very malicious payload, a drive-by attack, reconnaissance for something worse to come, a search engine crawler or the submission of a typographical error by a valid user? Sometimes you may not know without correlating data from different sources over a period of time. Having some sort of centralised logging, correlating and alerting system is required.

Take for example a page address (URL) that is only meant to be requested by a particular authorised source (user or system). This might be something like a simple form for suppliers to collect orders, an uptime monitoring target, a data import routine or data exchange facility. Let's assume the application script processing this URL validates the request format, the argument names and values, and source (perhaps by some combination of username, password, token, IP address and certificate). But what should be done if the request comes from an unauthorised source or fails one of the other validation checks?

Such requests could be restricted by a router, network firewall, web application firewall or even restrictions configured on the web server itself. It may seem most appropriate to add rules to the network firewall. In a simple web hosting architecture, this might look like this:

where the incoming invalid request (potential attack) is shown as a dark orange arrow. Of course, your architecture may include other types of application firewalls, load balancing and clustered servers in a 3-tier arrangement:

Even this more complex architecture doesn't show other servers and network devices that may exist such as network storage, authentication servers, intrusion detection systems (IDS), backup devices, the internal network, failover/standby systems, etc. But unless these systems log appropriately and these logs are incorporated into real-time alerting and monitoring systems, we might be none the wiser that someone (an "attacker") is having a go.

In many cases it may be better to let the request pass through the intermediate control points so that application itself can assess the request and, probably reject the request. But this means the application can record and report on this, and possibly use this information to combine with other anomalous requests.

Requests that could harm the web or application servers should of course be restricted earlier than this. But in the example of source constraints, it is better to ensure as much information about the source and content of the request is captured. A network firewall is not the best device for this.

The method implemented will depend upon what logging and correlating facilities are in place. If you have a central analysis server such as a Security Information and Event Management (SIEM), this may also be an option for controlling the blocking action with a number of possible prevention points.

The other problem with moving security controls away from the application is that there are potentially more configuration settings to implement, and the application itself may not be able to detect if these are in place. If the application has knowledge of attacks (by its own monitoring or via a SIEM), it may be able to be more strict with subsequent requests from the same source, or adjust its general security posture to a more defensive condition.

Input validation and output encoding are key aspects of web application security. This morning I've just been using a data search on a website and came across this when no results were found:

I imagine "escape(escape())" is some attempt at preventing cross-site scripting (XSS), but implemented correctly. Interestingly, when search results are found there are several "-->" appearing. Another indicator of output encoding problems.

It doesn't have to be difficult - read the OWASP XSS Prevention Cheat Sheet.

The first report on the state of software security has been published by Veracode who provide a cloud-based application risk management service.

The data presented in State of Software Security Report - The Intractable Problem of Insecure Software are interesting, it relates to both web application (40%) and non-web application (60%) software but spans in-house developed, commercial, open source and outsourced, developed in .NET, C/C++ and Java. But don't get bogged down in the data. I'd recommend that everyone responsible for web development, or who commissions or operates a web site, read the executive summary. I was quite surprised that backdoors (a method of bypassing normal authentication) are still a significant issue: "Open Source projects have ... fewer potential backdoors than commercial or outsourced software". This is why "V13 Malicious Code Search Verification Requirements" appears in the Application Security Verification Standard.

There are seven recommendations, which are in summary:

• Implement a comprehensive, risk-based, application security programme.
• Implement security acceptance criteria for third-party suppliers.
• Test code from outsourced, commercial and open source suppliers as rigorously as internally developed code.
• Verification of C/C++ code must not be ignored and it is likely to be present in many applications.
• Implement specific developer training on security.
• Learn from organisations in higher-risk sectors such as finance and government.
• Ensure security requirements are built into outsourced software development.

Some good advice there. The report provides a fuller description and gives the background to these recommendations.

I guess there must be much more detailed data available to Veracode than is presented in this "Volume 1". Perhaps Volume 2 will look at trends over time, but I'd also like to see:

• Breakdown of root causes (e.g. unvalidated user input).
• Breakdown of how the vulnerabilities had been fixed when the software was re-tested (e.g. parameterized queries implemented).
• What proportion of faulty code was identical — found in more than one application (i.e. copied/duplicated from elsewhere).
• Details of any secure development lifecycle in use by suppliers and their level of maturity with these.

Hopefully this type of aggregated data can be shared under Veracode's terms of service and agreements with individual customers. The software suppliers included in Veracode's analysis are likely to exclude customer organisations who do not have the knowledge or resources to have their code analysed. It would be an interesting research project to test a selection of applications developed by other suppliers to see how they compare.

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.

Today the UK Information Commissioner's Office (ICO) announced the publication of its report on the business case for investing in proactive privacy protection, which it is launching at the Data Protection Officer Conference in Manchester.

The aim of the research and report defined in the tendering brief was to create a soundly argued business case for expending money on privacy friendly systems and business processes. John Leach of John Leach Information Security Ltd and myself working for Watson Hall Ltd submitted a proposal to undertake the project for the ICO. We were awarded the contract in August 2009.

We began the project by producing a public discussion document and initiated conversations with a number of experts. Our research was complemented by interviews with a cross-section of data processors and discussions held with an expert panel. We were particularly concerned about producing a report that would be relevant across all UK business sectors and size of organisation. Our draft report was reviewed by a small number of senior business leaders, and modified based on their experience and knowledge of justifying investments and practical experiences of implementing privacy protection measures.

The result? Well I'd like your opinions after reading the report. The Privacy Dividend is comprised of two volumes:

• Volume 1 - The Business Case (20 pages)
• Volume 2 - Supporting Materials (71 pages)

I hope you find "The Privacy Dividend" a useful resource. Additional updates and references are included on the Business Case for Investing in Proactive Privacy Protection project microsite.

Last week I visited the London Design Museum on South Bank. One of the current exhibitions is about Dieter Rams—not someone I was aware of previously—who is head of design at Braun, the German consumer electronics manufacturer. The exhibition included scores of examples of products he has designed over 40 years; with many on loan from Braun's own archives.

Ten Principles of Good Design

But Rams' ten most important principles of good design caught my eye since it seemed they might apply more widely. I wondered how they might be applied to good security. Of course the ten most important security principles would actually be something else, but let's just look at Rams' ones.

Good design security is innovative

Technological developments offer new opportunities for innovative security. Security practitioners must innovate to meet new threats.

Good design security makes a product useful

Interesting in the security context. I believe that good usability includes good security and vice versa. Good security won't always make a web application useful, but equally good design can never truly make up for fundamental shortcomings of a product. Good security should enhance the application, not detract from it.

Good design security is aesthetic

I don't expect aesthetic quality to be mentioned any time soon in the ISO 27000 series of standards, but if we can achieve beauty, that should be preferred. For example, ugliness in user interfaces inevitably introduces errors in data selection and entry, and these may have a security impact.

Good design security makes a product understandable

Self-explanatory security? Yes, the inclusion of security measures should aid the user's understanding. Security measures should complement the software and make sense.

Good design security is unobtrusive

Security should not get in the way of the other functionality and where it is visible, its reason and method of use should be obvious.

Good design security is honest

Cut out the fear, uncertainty and doubt (FUD). For example, don't include claims about security (and privacy) that are not true or cannot be substantiated.

Good design security is long-lasting

Repeated changes to software are prone to introducing faults and should require a carefully controlled change management processes. By getting it right first, and not having to change security measures later, this makes better security.

Good design security is thorough down to the last detail

Building security in at an early stage by assessing the risks and requirements reduces the chance of having to make arbitrary decisions later or security implementation being left to chance.

Good design security is environmentally friendly

This one is harder, but perhaps good security uses resources more efficiently? It is certainly more expensive to fix faults later, so there could be an environmental benefit.

Good design security is as little design as possible

Purity? Simplicity? Architectural and programming code complexity leads to faults that may be security vulnerabilities. It is also difficult to maintain. Yes, keep it as simple as possible to achieve the security requirements.

Maybe in time we'll have security celebrities who adorn software packaging and interfaces with their signatures, like sportsman on clothing or chefs on saucepans. I don't think Dieter Rams would ever want his signature on one of his designs—they are enough of an inspiration without adding un-necessary branding.

Top Ten Most Critical Web Application Security Risks

There's a different "ten" being presented and discussed at OWASP London this Thursday: the OWASP Top Ten 2010 RC1. Web application developers should find the new document and associated cheat sheets a great help but it's very important for organisation subject to Payment Card Industry Data Security Standard (PCIDSS). As usual all meetings are free and open to anyone, but prior registration is required. The meetings are very popular, so register now if you haven't already.

It seems we are spending about ten times as much on infrastructure security as application security.

This is the conclusion of Jeremiah Grossman in his post on Infrastructure vs. Application Security Spending using some broad calculations and estimates from the available information. Have a look at the referenced sources and comments, and keep an eye open for the next web application security spending benchmark report.

What is your organisation spending on these two aspects?

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.

This weekend I'm going to a fancy dress party with a theme of film actors and characters, and was looking for Toy Story Buzz Lightyear gear.

One price comparison website listed a Buzz Lightyear toy at £999999.00 which seems rather high. It was either made from something very valuable, or an error.

How do you validate pricing information being added and also when displayed? Who/what can alter pricing, discounts, additional charges, tax rates, etc on your e-commerce web site? What approval processes are in place? Who is accountable? All data should be checked for reasonableness, type, format, characters, length, encoding, etc. Reporting/alerting on changes might also help detect this type of issue.

And, make sure your terms state what happens if a price is "incorrect" and exactly when a contract is formed.