Twice this week I have referred people to a unique centralised resource of information topics about programming in Java.

John Melton spent a year of his life (no, actually more like a few hours a week for 52 weeks), writing blog posts in his series Year of Security for Java (introduction, conclusion and listing). I have worked with John on aspects of the OWASP AppSensor project, and had the pleasure to meet him in person during AppSec USA 2011 in Minneapolis.

If your company develops in Java, you should reference these in your intranet or development portal — John has created a PDF comprising all the Java security posts.

One of the best sources of application security information and news is the OWASP AppSec Moderated News Feed. It's a gold mine of material.

A nugget I have just caught up with is Jerry Hoff's announcement of a new OWASP project named Framework Security Matrix. The Matrix is a free spreadsheet which maps out which baseline security controls are available in common development platforms, languages and frameworks.

Knowing what is inherent, what can be selected optionally and what must be built by hand is extremely useful. We must thank the hard-working Jerry Hoff along with the project's other contributors John Melton, Harry Papaxenopoulos and Raymond LeBlanc.

It took me a while to hear about a recent research report from the Ponemon Institute regarding application business logic attacks.

2012 Web Session Intelligence & Security Report: Business Logic Abuse Edition, published in early October, describes the results of a survey of 425 United Kingdom IT and IT security practitioners with some responsibility for the security of their transactional website and who were familiar with logic abuse. A parallel report details the survey of 643 similar professionals in the United States of America. In these studies, business logic abuse is the mis-use of intentional web site functionality to "perpetrate cyber attacks, hacks or fraud".

The most interesting figure is that 90% of companies lost revenues due to the financial or brand impact of fraud (alone?), and 20-25% lost more than 5% of their total revenues. The business logic abuse scenarios presented are web scraping, account hijacking, click fraud, botnets causing denial of service, electronic wallet exploitation, coupon abuse, testing stolen credit cards, mobile device malware to take over customer accounts, app store/marketplace fraud, and mass registration.

However, I was most interested to see what these IT and IT Security practitioners considered ought to be the steps that are taken to detect or prevent business logic abuse. The answers appeared to be selected from a pre-defined list provided in the survey, with "Manual inspection and assessment of web pages" during development and in production seemingly being the two most "important or very important" methods (each by about 50% of those responding). This is not "business logic security testing" since "thorough testing of the website's functionality prior to production" was a different item and considered important or very important by 20-30% of those responding.

But there was no mention of defining security requirement in advance, secure design, threat assessment, manual and automated code analysis, etc, or of building attack detection and prevention into the web sites themselves. Yes, web application firewalls (WAFs) and "content aware firewalls" were mentioned, and it seems the surveys' authors and respondents are very biaised towards operational practices.

The reports' conclusions appear to have missed that the activities are generally too late (not just too little), and that a range of security practices are needed throughout the software development life cycle (SDLC). However, the reports' recommendation to assign responsibility for web site security is correctly the most important first step.

A very comprehensive report by the Boston Consulting Group, that assesses the value of digital identity, has been published by Liberty Global.

The Value of Our Digital Identity, describes consumers increasing awareness and desire for control and how user control increases the willingness of users to share data. The report highlights how unlike some commodities, as the volume and variety of digital data grows, so does its value. And this data explosion is being driven by digital services & media, online data transactions, the internet of things and the current boom in social media, In turn this can fuel economic growth.

The report attempts to define what digital identity is, quantifies the current and potential economic value of digital identity for organisations and consumers, identifies important trends and offers a set of guiding principles that could help responsible organisations benefit from the value of digital identity.

Topics included that may be of particular interest to those involved with application design and implementation include:

• Problems when there is a lack of transparency for users about how their personal data is collected and used
• The benefits of offering the right to be forgotten
• How the the form of consent should be based on the type of data requested
• The need for convenience (usability)
• Sector-specific variations in user behaviour
• The requirement to increase data security (and not just using technical controls)
• Why there should be flexibility in regulation to allow users to make their own choices
• How digital identity can be used to provide differentiation from competitors

The report suggests that organisations need to establish and promote a trusted flow of data, or otherwise there are significant lost opportunities for value generation. Read, digest and implement.

SSL certificate validation is an essential aspect of creating trusted, secure links between client devices and servers. This is often undertaken between a web browser and secure web server using Secure Sockets Layer (SSL)/Transport Layer Security (TLS).

In this situation any certificate error warnings are visible to users to an extent, and result in changes to web browser chrome (such as colour changes) and in some cases warning messages. However, users are not generally aware of server-to-server SSL connections, and these too need to check the validity of the public key SSL certificate.

In the paper The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software by M. Georgiev, S. Iyengar, S. Jana, R. Anubhai, D. Boneh and V. Shmatikov describe their research into application software and code libraries which set up and use SSL connections. The authors describe how many checks (host name, period of validity, intermediate & root certificate authorities and revocation) are not always being performed. It would appear to be a combination of unimplemented functionality or the alteration/selection of insecure code library options instead of using secure defaults. Some of the latter is attributed to confusing, missing or hard to find documentation.

While I think some of the headline quotations from the paper are somewhat sensationalist, and to an extent, unfair on some of the code libraries mentioned, the authors are correct in their recommendations for application developers and SSL library developers. The recommendations identified for application developers are:

• Use fuzzing and adversarial testing to check the response to abnormal certificates
• Check SSL library default configuration settings and explicitly set the necessary options
• Do not modify application code relating to certificate validation for the purposes of testing
• Do not disable certificate validation during testing with self-signed or untrusted certificates

These items should be reviewed in software development implementation, testing and deployment practices.

If you are considering using social sign-on on your web site, a recent paper is worth reading

Discovering Concrete Attacks on Website Authorization by Formal Analysis by Chetan Bansal, Karthikeyan Bhargavan and Sergio Maffeis, discusses the required security goals and related web-based attacks. In particular it explores the issue of cross-site request forgery (CSRF) which can be amplified by using social sign-on where the user is authenticated by a third party social web site using protocols such as OpenID (Google) and OAuth (Facebook).

The paper presents some more advanced mathematics and undertakes a formal analysis to identify some known attacks and predict others.

Do read the paper, even if you skip through some of the analysis.

Nominet, the .uk internet registry, is consulting on a proposal to create unlimited second level domains (SLDs) using .uk (e.g. clerkendweller.uk instead of clerkendweller.co.uk).

The consultation document steps through the proposals and asks for responses to a number of aspects:

• Security
• Verification of registrant contact data
• Third level sub-domains
• Reserved and protected names
• Phased release and rights management
• Channel to market
• Existing second level domains
• General views

The security section proposes malware monitoring and notification, a mandatory digital signature to prevent the hijacking of a domain name (DNSSEC), and discusses how the new SLDs could be used as a trust mark. This would appear to reflect ideas published by the House of Commons Science and Technology Committee for a software security kitemark (at least for web sites).

I welcome the idea of building trust, but the bar is far too low.

I do not believe use of DNSSEC, initial and subsequent periodic verification of contact details, combined with some sort of commercial malware monitoring and notification are sufficient indicators of the safety of a web site for users and their data. The spread of malware is not the only risk to web site users. Trust needs to consider availability, prevention of misuse, protection of the data from breaches in confidentiality, maintenance of accuracy, and compliance with various mandates (e.g. legislative, regulatory and contractual such as PCI DSS). The processes for web site development, configuration and operation can all affect users and their data. These issues require a balanced combination of administrative, technical and physical controls, and thus are are not simple and cannot be determined by an automated scan.

Whatever measures are finally agreed, they should apply to new registrations and renewals of third level domains (e.g. co.uk and org.uk), not just for the proposed SLDs. Otherwise lack of trust in the current domains will undermine trust in the others.

The consultation closes on 7th January 2013. Responses can be sent by post, email or using an online form.

I was not able to attend AppSec USA this year, and I have been envious of those who did go.

Dinis Cruz highlighted one of the presentations by Nick Galbreath titled Rebooting (Secure) (Web) Software Development with Continuous Deployment. In the presentation, Nick discusses problems in software development and proposes that giving full control of deployment to developers and moving towards a model of continuous deployment, can contribute to more secure software.

Some great ideas worth investigating there.

Th excellent Building Security In Maturity Model (BSIMM) survey of secure software development practices has been updated again.

BSIMM v4 was released in September and now includes data from 51 companies across a dozen sectors, including 19 each from financial services and independent software vendors.

The data is richer since 13 of the companies have now been assessed twice, and one thrice. The summary data on pages 57 and 58 identify 12 objectives/activities that were found to pe present across the secure software development life cycle (S-SDLC) process of all companies, and the prevalence of each activity in the total set.

There's an intriguing new project aiming to raise awareness and increase understanding of information security.

The Analogies Project plans a series of initiatives to communicate contribution of information security to society. The first initiative will be a book showing the relationship between life, information and information security.

The founder Bruce Hallas will be speaking about the project at the next meeting of white-hats.co.uk tomorrow morning. Booking required.