It's good to see different groups working together to improve security. This week another browser manufacturer announced future support for an initiative relating to Transport Layer Security (TLS, the successor to SSL).

HTTP Strict Transport Security (HSTS) describes a method for a web site to tell client browsers that they should only interact with it over secure transport, i.e. TLS Whilst there have been browser plugins which support this draft specification, support for HSTS was announced for v4 of Google Chrome in January, and last week for v4 of Mozilla Firefox. Hopefully Microsoft Internet Explorer 9 and ,a href="http://www.opera.com/">Opera will also adopt this.

Why is it important? Some attacks mean that TLS is vulnerable if there are redirects from non-TLS (e.g. http://www.example.com) to TLS (https://www.example.com) content. And if part, or all, of your web site is only meant to be accessed over SSL, HSTS should be implemented now, ready for mainstream adoption.

Further details are provided on the W3C page at Strict Transport Security (STS) and the draft IETF specification is at HTTP Strict Transport Security (HSTS).

I have been exploring further the possible response actions an application might make once it has detected a suspected or actual attack, as a contribution to the OWASP AppSensor project. There is now a draft document describing response actions, discussed and announced last week.

The draft document AppSensor - Response Actions describes thirteen response actions, provides examples of each, and discusses how they might be categorised in order to help with selection of appropriate responses.

It is still a working document. If you have any suggestions or comments on the draft document, please send them to the AppSensor project's mailing list, or perhaps add them below. In particular, I'd like to discuss whether there are any other responses which aren't covered by the ones already included.

There is additional background information and links relating to web application intrusion detection and the OWASP AppSensor project in my posts about presentations in Newcastle and London, but I hope to present again later in the year.

Investment decisions for loans, mergers & acquisitions in primarily online businesses need just as much care as investing in more conventional businesses.

This month I contributed to the Autumn 2010 newsletter of DeVere & Co, risk management, fraud and asset recovery specialists, with an article about Ecommerce Due Diligence. In the article I discuss some of the specific issues relating to due diligence of online/e-commerce websites and applications including intellectual property, third parties, sensitive data, security operations and customers.

E-commerce sites often link many different systems and it is necessary to identify the relationships, boundaries, agreements and assumptions. Asset ownership is not always as clear-cut as expected. Let the buyer beware!

A few weeks ago I mentioned two new research papers about the use of passwords on website. Another new paper from Microsoft Research and Harvard University discusses how to avoid, and protect web sites from, users selecting popular passwords.

The paper Popularity is Everything: A New Approach to Protecting Passwords from Statistical-Guessing Attacks describes online and offline threats and defences against the sue of common popular passwords.

Password implementation policies can be guided by legacy approaches and various standards, but as mentioned previously, economics plays a large part too. Following a much publicised successful brute force against Twitter accounts, the company increased its password requirements. But rather than forcing passwords to be more complex, they instead took the decision to prevent the use of 370 common passwords. Whilst the list is culturally-biased, due to other breaches, there is similar data from other sites (e.g. here and here). But how does banning popular passwords help, and if the lists of common passwords are known, does this matter?

Firstly I'll mention here a couple of typical online tools for determining password complexity:

• Password meter providing an indication of complexity
• Hammer of God providing an estimate of how long it would take to obtain the password using a brute force attack

Don't put your real passwords into these sites or any other checkers! But these types of tools do not take into account popularity (e.g. '123456') or common manipulations (e.g. is 'P@ssword' really that much more secure than 'password'?). If attackers try popular passwords first (i.e. a dictionary attack), the time to break into a user's account may be much shorter.

The research paper, which does include some mathematics, suggests that simple passwords should be allowed providing they are not subject to statistical guessing attacks and proposes attack detection methods.

Good reading and inspiration for password-based authentication systems. I'm off to the station now, to get a train to Newcastle which was cancelled last night.

I have been meaning to write again about web application security logging, but luckily read a paper last week which provides excellent guidance.

How to Do Application Logging Right is the best guidance I have come across to date. Co-written by Anton Chuvakin and Gunnar Peterson for the IEEE Security & Privacy Journal, the paper describes the problems with typical logging systems, what events need logging, and for those, what to include and exclude. They have also provided some broader guidance on log management and protection.

Previously, the most notable application security logging guidance existed buried rather deeply in the documentation for OWASP's ESAPI Java edition, the OWASP Logging Project, and more general guidance in NIST's SP 800-92 Guide to Computer Security Log Management.

If you read those in conjunction with the new paper, and perhaps Chuvakin's and Peterson's own comments, you'll be well up to speed.

The content of the "module", "object" and "action" fields will be dependent upon the degree of granularity required and how much additional event information is collected as additional details (e.g. stack trace, request headers, response body). I believe a transaction ID should always be included so that all events for a single request/response can be more easily correlated—this has a request scope rather than the session scope of a username/id. If I might suggest some other additional items for "what to include", I would also consider:

• host address (e.g. host name and domain, or server IPv4 or IPv6 address) which is useful if clustering is being used, or to confirm logs are from live rather than staging systems
• service (e.g. name, port and protocol)
• full actual entry point URL (protocol, full domain, port, path and further parameters)
• canonicalised entry point URL
• HTTP method (for web applications)
• responses seen by the user and/or taken by the application (e.g. status code, custom text messages, session termination, administrator alerts)
• analytical confidence in the event detection (low, medium, high or a numeric value).

Full request headers and possibly the response body may be worth collecting for some events. But ensure these are sanitised for sensitive input such as passwords, session cookies or credit card numbers.

I would also tend to use a severity scale (0=emergency, 1=alert, ..., 7=debug) rather than the suggested "priority" field, for consistency with syslog protocol. But the paper's authors note that whatever scale is used, it will be different for each organisation due to their own priorities and views on risk.

You may also want to consider how the integrity of the logged information can be determined.

Whatever you log, bear in mind you probably want it to be relatively human-readable, but also done in a way you can share the information with other systems. For the moment, consider Common Event Format (CEF). But Common Event Expression (CEE) is an ongoing collaborative effort to develop an event interoperability format summarised in a presentation, and in more detail in a white paper. The CEE web site includes a description of alternative approaches for sharing data from event producers.

See also my previous web application logging related posts How Much Logging, Monitoring and Alerting?, Security Logging Requirements, Testing the Audit Trail, Don't Stop the Attack (Too Soon), and Application Log Management and Analysis.

Happy application logging!

PCI DSS and PA-DSS standards changes have been pre-announced by the Payment Card Industry Security Standards Council (PCI SCC).

Yesterday's announcement, which also includes notice of changes to PIN Transaction Security (PTS) requirements, provides a summary of the upcoming changes to v2.0 of PCI DSS and PA-DSS due in October 2010. Apart from increased alignment between the standards, the upcoming changes are meant to provide clarifications, additional guidance, new requirements and provide ways to improve organisations' flexibility to implement controls using a risk-based approach. There is also mention of a more forward-looking approach with guidance on managing evolving threats.

The indication that a risk-based approach is to be recommended for assessing vulnerabilities is a welcome change. This of course needs to be undertaken with a real regard of the risks to the business and its customers, clients and citizens, not just the data itself. The references to additional sources of good coding standards and vulnerabilities is encouraging.

The new standards are expected to be published on 28 October 2010 and will come into force on 1 January 2011. This will be quite a tight deadline for many operators to ensure they continue in compliance. The press release also includes details of upcoming meetings and webinars where additional information will be provided by the PCI SSC.

The UK Centre for the Protection of National Infrastructure (CPNI) have published new guidance on understanding and managing the risks from phishing and pharming.

Whilst most readers of this blog won't work on projects considered part of the national infrastructure, that doesn't mean you should ignore good, free advice.

The CPNI document discusses the threats and impacts (on employees, customers, clients and citizens), the modes of attack and possible countermeasures. I'm pleased to see that countermeasures to reduce the likelihood of successful attacks include both technical and cultural measures. Measures to mitigate the effects of successful attacks are also discussed.

Although some of the document is necessarily technical in places, the case studies in Appendix C should make sense to everyone. Remember, this is about business risk, not technical risk. The "I don't understand technical things" argument does not stand up.

Of course, assessing and implementing information security policies and controls is hardly ever simple or quick. But with the government's aim to reduce the number of different web sites this process may be a little easier. It's good to see such guidance, especially when the Central Office of Information (COI) has to date avoided the subject of security in its own web standards and guidelines. In view of the perception that the government isn't keeping up with threats (for example see the response to the petition to upgrade away from Internet Explorer 6), how are the CPNI phishing and pharming countermeasures being implemented by the government?

Knowledge about the degree to which the cultural countermeasures have been adopted within the government sector cannot be adequately measured from outside, and it would be good to see these included in work performed by the National Audit Office. Similarly most of the technical countermeasures would require privileged access to government networks (and permission!). However "use of SSL and TLS" and "signing of digital communications" should be easily observable, without doing any testing, from the outside world.

These two measures have security benefits beyond protection against phishing and pharming. They can assist citizens wanting to verify the identity of, and rely on the integrity of the information they see on what looks like a government web site, or receive in an official-looking email or other form of correspondence, perhaps during a national emergency. These types of event can attract themed phishing attacks for example. I haven't received any official government electronic communications recently apart from reminders from HMRC about tax deadlines and the like, so can't comment on how the sender and data integrity is verified. The tax reminders don't contain any sensitive data, and occur when there are known forthcoming business events or relate to actions undertaken by myself, so correctly don't need the same degree of verification.

But anyone can visit a web site, so what about those? Well, the CPNI web site appears to also be available over SSL/TLS as we'd expect. But, looking at https://www.direct.gov.uk using SSL (now more correctly called transport layer security, TLS) in the Chrome web browser, I was a bit surprised to see:

and this is the same for the prime minister's web site at https://www.number10.gov.uk/. Another possible primary governmental address is https://www.hmg.gov.uk which gives:

Maybe these have been deemed to be acceptable risks. But let's hope the other recommended countermeasures have been implemented.

The UK's Office of Fair Trading (OFT) promotes and protects consumers' interests by ensuring markets work well, and that businesses act fairly and competitively. The government has asked the OFT to develop a longer term national strategy for consumer protection and enforcement on the internet. The strategy is intended to promote a safe and vibrant internet market.

As part of this strategy development, the OFT has launched a consultation on E-consumer Protection. The objectives are to improve the effectiveness of online markets and increase the level of consumer trust, so that consumers have a real option to use the internet for transactions, as equally as any other channel. The aim is also to ensure that enforcement of consumer protection online is as good as anywhere else in the world.

The main consultation document outlines some useful statistics about the UK internet economy using data from the European Commission's Consumer Markets Scoreboard 2010, the OECD and the OFT's Attitudes to Online Markets (publication due shortly). For example, 71% of the UK's retailers use e-commerce/internet sales channel for retail, and internet/online accounted for 9.5% of UK retail trade (£38 billion) in 2009. Apparently UK consumers have a high level of trust in UK sellers/providers' protection of their consumer rights and that they are adequately protected. However, it is not all good news as almost 20% of UK internet users are not transacting online, with a third of these stating concerns about the security of their personal and financial information as the reason. Overall, two-thirds of all internet users are worried about unauthorised access to their personal information. There are also concerns about being conned by companies online. The consultation document outlines how consumers may be becoming complacent about security but that they lack awareness of issues such as mis-use of cookies and behavioural advertising.

The OFT suggests these problems reduce confidence, lead to lower levels of demand, and consequently lower levels of supply. Households can miss out on potential savings and this is especially problematic for low income households (LIH). The consultation document proposes that agencies should work together to empower consumers, promote business compliance and develop effective enforcement. It proposes a number of high-level actions under the themes of consumer education, tool provision and hardening, business information, cooperation and deterrence, and enforcement capability building, coordination and leveraging intelligence.

The outcome of this consultation will have a large impact on organisations in the business-to-consumer (B2C) sector (there is also some discussion of whether C2C should also be addressed). If you are an online retailer, perhaps get in touch with your trade organisation and ask them whether they are responding, or do so yourself.

There are five general response questions, and further more-detailed questions about the high-level actions and monitoring proposed. Responses can be submitted online, by email and by post. The consultation period closes on 13th October 2010.

This year I have mentioned web application security programmes, how software vulnerability testing recommended risk-based, application security programmes and generalised results from a survey about web application security programs.

But what are enterprises doing in real life and what are the issues? During the second day of OWASP AppSec Research 2010, Michael Craigue of Dell presented on Secure Application Development for the Enterprise: Practical, Real-World Tips. Although I missed it, people who did attend this track were enthusiastic about it and the video recording has now been published. I watched it last weekend.

Michael described Dell's 10-strong Global Information Security Services group and how it works with 3,000-5,000 developers in internal teams and how their appsec work is built on a published and maintained secure application development standard. Some of the problems encountered at Dell were platform diversity, security expert retention, the need to develop self-help documentation for the low and medium risk projects, lack of good metrics around security awareness training, high overhead of conventional threat modelling and the need to build security into the development lifecyle slowly, and in a business-focused manner.

At Dell, the project risk is calculated from ten factors including data classification, compliance requirements, whether it is externally facing, and the security knowledge of the development team. Interestingly, in the final questions from the audience, Michael mentioned Dell are using Open SAMM to identify gaps, measure how well their security programme is performing and to focus improvement efforts. Even projects that the group does not get involved with directly, are subject to quality checks and audit such as using Control Self Assessments (CSAs), which look for the artifacts required in the self-help documentation, even for low-risk applications.

There is another description of how software assurance practices at Ford in 2009, and recently published on US DHS's best practices web site Build Security In. The Ford programme is quite different. Every application security programme is unique because every organisation's culture, application and acceptance of risk is different.

What is yours like?

Two great papers on web site password security were published this month. We are swamped with passwords and every daily activity is increasingly linked with an online version, which requires users to register to obtain some additional benefits. Every organisation, resource, activity and event encourages us to visit their own website and sign-up.

Firstly, in Where Do [Password] Security Policies Come From?, Dinei Florêncio and Cormac Herley of Microsoft Research discuss the password policies of 75 different web sites, in an effort to determine password strength requirements with other aspects such as size of site, assets protected, number of users and frequency of attacks.

The authors' findings suggest that none of these are the key factors, and in fact some of the largest sites, most attacked and with higher-value assets have the weakest password policies. The authors suggest stronger policies exist where organisations are more insulated from the consequences of poor usability, whereas online retailers and sites that rely on advertising revenues have to compete rigorously for users and traffic. The paper also discusses how strong passwords need to be, and how this is affected also by what attack methods you are considering (e.g. online vs. offline brute-force), and whether other security controls are implemented (e.g. account lock-out).

This idea of considering the whole password environment is taken further in The Password Thicket: Technical and Market Failures in Human Authentication on the Web by Joseph Bonneau and Sören Preibusch at the Cambridge University Computing Laboratory, and presented at this year's Economics of Information Security (WEIS 2010). Their study included 150 web sites looking at password implementations. the study looked more broadly at the protective measures used— not just complexity requirements—but whether these were applied consistently across the site's functionality (e.g. registration/enrolment, log-in/authentication, password change, password reset/recovery, log-out), encryption during transmission, storage of passwords in clear text, inclusion of passwords in emails, as well as protection from brute-force attacks.

The authors found that stricter security in one area was often undermined by weaknesses in another, suggesting that a lack of standards is harming security. The paper also discusses economic interpretations, such as how deploying passwords might be being used to justify collection of marketing data, and how password insecurity can be a negative externality.