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!

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!

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.

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?

Mobile Web Application Best Practices has been published as a last call working draft by the W3C Mobile Web Best Practices Working Group.

Mobile Web Application Best Practices is intended to to aid the development of rich and dynamic mobile web applications. It includes guidance sections concerning application data, security & privacy, user awareness & control, (conservative) use of resources, user experience and handling variations in the delivery context.

The document defines "web application" as:

However it also states the 32 best practices are equally applicable to other kinds of web run-time, such as widgets and vendor-specific initiatives.

Unfortunately there is only one recommendation relating to security & privacy. If I had to choose just one security or privacy aspect to raise with mobile web application developers, I don't think it would be "Do not Execute Unescaped or Untrusted JSON data". From a business risk point of view, injection flaws would probably be my choice, and that may also be the same from the user's perspective. Worrying about privacy options is irrelevant if someone can steal all the information from the databases. Of course choosing just one is difficult but I believe additional, perhaps broader, guidance is needed here.

The W3C are seeking comments on the document which should be sent to public-bpwg-comments@w3.org before 6th August 2010. There are specific instructions for feedback from mobile web application implementers.

Visa Inc has released a guide to Card Data Tokenization Best Practices.

The intention is to provide guidance on using non-sensitive surrogate values (tokens) as a proxy for card data (typically the primary account number or PAN) by merchants, vendors, service providers and acquirers. This in turn can reduce where card data exists, and therefore the scope for compliance with the Payment Card Industry Security Standards Council (PCISSC) Data Security Standard (DSS). The guidance joins other information in Visa'a Cardholder Information Security Program (CISP).

The guidance describes Visa's best practices for the tokenization system, token generation, token mapping, the card data vault (the secure repository that maps tokens to cardholder data), cryptographic key management and the management of historical data.

However the guidance may not generally accepted and is being debated here and here, especially with regards to reversibility of the process and the use of salts when hashing, but Visa are seeking feedback on this first version, and have asked for responses by 31 August 2010 to be sent by email to inforisk@visa.com.

Following a consultation process earlier this year, the European Payments Council has published the first edition of a white paper on mobile payments.

The European Payments Council (EPC) supports and promotes the creation of the Single Euro Payments Area (SEPA). In this white paper, the EPC sets out to present an overview of mobile payments (contactless and remote) for SEPA, and the initiation of of payments via the mobile channel leveraging existing SEPA payment instruments—SEPA Credit Transfer (SCT), SEPA Direct Debits (SDD) and SEPA for Card Payments. Whilst this is not a technical document there is some mention of the security aspects.

The paper describes the business rationale for mobile payment services, example usage scenarios and the business & technical aspects for mobile contactless (proximity) card payments. The payment scenarios include access to premium web content using credit card payments and also direct debit subscription services. If you are scoping out usage scenarios for future services which may involve mobile payment, the descriptions and diagrams are invaluable. Further implementation guidance is expected in due course.

A second edition of the white paper is due in the first part of 2011 that will contain more detailed information about mobile remote payments.

My previous mention of the Financial Services Authority (FSA) had suggested they would survive the new government in the UK. This is no longer the case as the FSA is to be broken up by 2012.

But regulation continues for the moment and, following a review undertaken in February, the FSA has published a new update on Financial Promotions Using New Media. New media communication channels include "social networking websites (Twitter and Facebook), forums, blogs and i-phone applications". So presumably any web site or mobile phone application where a regulated firm communicates.

The guidance explains the rules relating to the content of communications (e.g. stand-alone compliance and communication rules contained in COBS 4, BCOBS 2, ICOBS 2 and MCOB 3) are no different than for other media, and includes non-promotional communication such as directly with existing clients.

So what extra guidance for new media is there? The document highlights:

• regular reviews are required to ensure information is up-to-date
• some channels may be inappropriate for the particular communication to ensure it is balanced and provides sufficient information (e.g. Twitter where the length of each message is very restricted)
• consideration as to how risk information can be highlighted varies across the channels.

The FSA notes that most new media communications does not benefit from the exemptions for image advertising.

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.

Do You Have SSL Configured Correctly? Let me start by saying that "correctly" means "best for you". There isn't a single correct answer, although there are certainly some "don'ts" that apply in every situation.

This information is not about whether to use SSL, and is mainly for your systems folk (or hosting company), but do read on and perhaps gain a better understanding.

Ivan Ristić recently announced the SSL Server Rating Guide (draft 10, 21 July 2009) and an associated online assessment tool called the Public SSL Server Database. These had reminded me to post my comments last Tuesday about the slightly related Colour Overload with IE8 Tab Grouping.

The SSL Labs' resources describe, and allow you to check, the SSL configuration of your own, or any other public site that has SSL enabled. The checks span the certificate and three categories of web server configuration settings. Previously, it needed more specialist tools that most people wouldn't have the time or inclination to use.

The rating guide contains much useful information, but will be too detailed for many people. However, do read the "Minimal Configuration Requirements" and pass these on to appropriate person responsible for the configuration and operation of your own web sites. Not every site needs an overall rating of 73 or 85 or whatever. You'll see in Table 6 of the guide, an idea of what might be suitable for a range of web site types.

After all, your competitors, and some customers, have probably already checked your site.