After attending the London Web Performance Testing Group on Wednesday evening, I went along to the London Android Group (londroid) at Skills Matter.

Mixing Native and Web Technologies, Oh My included three presentations/demonstrations. Great stuff.

Dave Springgay spoke about his experiences at News International developing highly crafted news apps which provide high quality and high performance on native mobile operating systems. He explained their use of HTML5, Android WebView and Java bridging to use JavaScript to inject content (mainly JSON) directly into pre-built HTML templates which are customised for each device, and which can be updated without re-deploying the app.

Jonathan Anthony provided an overview of the advantages of building mobile applications as webapps, using PhoneGap, using Titanium, and finally as native apps. He explained the latter of course give the best performance, better graphics and access to all the hardware APIs (with geo-location and camera being the most popular) along with the ability to have an icon on the desktop, but come at a cost due to the higher rates for developers, and the need to develop for at least two operating systems (i.e Android and the other one). He thought that for many apps, a webapp should be considered, due to speed of development and the cross-platform capability making them perhaps a quarter of the price.

Finally, Doug Chisholm and Clinton Smith described the capabilities of appsplash to develop cross-platform applications using their custom development platform.

So that's the technologies presented, but jQuery Mobile and jQTouch were also mentioned. Plenty to keep tabs on.

Happy new year. Planning your diary already? Looking for the best European conference for information about application security?

Europe's premier application security conference, AppSec EU, is being held in Athens, Greece, from 10th to 13th July 2012. As in Stockholm two years ago, this event has a research theme, but there will be plenty of practical information, advice and application security training.

In May I participated in the OWASP Greece chapter Training Day in Athens and was overwhelmed by the level of attendance from the enthusiastic and knowledgeable development community. I am sure the sponsorship opportunities and tickets will be snapped up quickly.

AppSec EU Research 2012 is being hosted by the Department of Informatics and Telecommunications of the University of Athens.

Another report from the European Network and Information Security Agency (ENISA) highlights deficiencies in the maritime sector.

The study's report Cyber Security Aspects in the Maritime Sector discusses that while there is increasing knowledge concerning physical security and crew safety, maritime cyber security awareness is low to non-existent. The situation is made worse by fragmented responsibilities, lack of incident information, and missing legislation in this area.

A relatively quick read if you are active in the sector.

Further to my previous notes about HTML 5 security, a superb reference document was published earlier this month.

Michael Schmidt (Compass Security) wrote his master's thesis about HTML5 security in May 2011 and has published an extract for everyone to access.

HTML5 Web Security describes issues, vulnerabilities, threat & attack scenarios and countermeasures across 80 pages including numerous well thought-out diagrams, and is backed up with detailed references and an appendix full of attack details.

The main sections are:

• 2.2 Cross-origin resource sharing
• 2.3 Web storage
• 2.4 Offline web application
• 2.5 Web messaging
• 2.6 Custom scheme and content handlers
• 2.7 Web sockets API
• 2.8 Geolocation API
• 2.9 Implicit relevant features of HTML5
  Web workers, new elements, attributes and CSS, Iframe sandboxing and server-sent events

If you are already developing HTML, or planning to, read this document as soon as possible and update your requirements documents, specifications, design documents, coding standards, and test plans to incorporate the knowledge.

The document would be worth buying if it were a book, but it has generously been made available publicly. Yes, I am still reading the document, and so far have only one very minor complaint — it would be good to have a content list. Maybe in version 1.1?

This week, the Cloud Security Alliance has announced its new repository of security control self -assessments for cloud computing providers.

The CSA Security, Trust and Assurance Registry (STAR) lists providers who have completed and submitted a Consensus Assessments Initiative Questionnaire (CAIQ) or Cloud Controls Matrix (CCM) response to indicate their compliance with CSA best practices.

Currently only two providers are listed, but more are in progress. This will be a very helpful resource for those seeking assurance about controls from suppliers, and potentially standardise the way cloud providers publish information about their security practices, simplifying procurement processes. If you are an IaaS, PaaS or SaaS provider, the existing submissions may help your own controls development or completion of an assessment.

There is more information in the detailed FAQ and LinkedIn forum.

Last week the UK government's Cabinet Office published its new cyber security strategy.

The Cyber Security Strategy describes the government's commitment to this "tier 1" risk. In the objective to make the UK "more resilient to cyber attacks and better able to protect our interests in cyber space", I hope the "risk-based approach..." "...working in partnership" which includes "raising business awareness" includes helping organisations of all sorts acquire and develop software which is secure and fit-for-purpose.

In particular, I hope the Cyber Security Hub will be able to promote secure software development lifecycles.

Undertaking training for developers and documenting secure coding guidelines are two of the earliest activities that should be undertaken in software security initiatives.

It is good to see Mozilla has published its WebAppSec Secure Coding Guidelines.

These show that secure coding guidelines neither need to be long nor overly complex. And yes they have to be tailored to your own development practices and risks. Read, re-use and reinvent.

Building Security In Maturity Model (BSIMM) version 3 (BSIMM3) was released on Tuesday by Cigital and Fortify.

Building Security In Maturity Model is an analysis of the results from a detailed surveying process about how companies build security into their software development processes. Its aim is to help all organisations understand, assess and plan software security initiatives. The findings identified are grouped into 12 practices across four domains called governance, intelligence, SSDL touchpoints and deployment in what is called the Software Security Framework. In these practices, a total of 109 activities are defined, spread across three tiers of complexity (levels 1 to 3) to give the appearance of a maturity model.

BSIMM3 includes data from 42 software security initiatives — 12 more than in BSIMM2. Although the data is primarily collected from organisations in the financial services, independent software vendor and technology sectors, other sectors are represented too. Many of the programmes are large, with the average number of developers being over 5,000 — but it ranges from just 10 to 30,000. No organisation survey does all 109 activities.

With the increase in source data, there has not been any significant change the the general findings, and the structure of domains, practices and activities has virtually not changed at all. The descriptions for most of the activities have been extended to clarify the meaning and provide further examples; in a small number of cases minor corrections have been made. But the total number of activities in unchanged, and their titles are the same. The following activities have been demoted from level 2 to level 1:

• Strategy & Metrics (SM) 2.4 "Require security sign-off" is now SM 1.6
• Attack Models (AM) 2.3 "Gather attack intelligence" is now AM 1.5
• Security Testing (ST) 2.2 "Allow declarative security/security features to drive tests" is now ST 1.3
• Penetration testing (PT) 2.1 "Use pen testing tools internally" is now PT 1.3

One activity has been promoted from level 1 to level 2:

• SM 1.5 "Identify metrics and drive initiative budgets with them" is now SM 2.5

So, previous scoring under BSIMM2 will need to be re-calculated, but there is a one-to-one mapping, and the numbering of all other activities remains unchanged.

The new scorecard presentation format demonstrate how to do a comparison of your own initiatives at a glance, and since some of the data sources have now been assessed more than once, BSIMM3 provides some comparison of changes over time.

So, some useful information for organisation wanting to assess and build out software security initiatives. Also take a look at Building Security In, Microsoft SDL, Open SAMM.

After an exciting trip to the United States, the very encouraging interest in OWASP AppSensor, and the productive AppSensor Summit, I'm back in the UK and catching up on a few things.

While I was away, a podcast interview has been published in advance of RSA Conference Europe 2011 where I am speaking about application-specific defences. In the podcast I explained the concepts but during my presentation will discuss specifications, requirements for procurement as well as building application-specific defences into your own development practices.

If you want to find out more, please come along to the Windsor Suite at RSA Conference Europe on 13th October at 13:00 hrs.

Following the busy Thursday, I returned to the Minneapolis Convention Centre on Friday.

I began the second day of AppSec USA 2011 on the OWASP track, where I was speaking in a session shared with Michael Coates.

Michael described the objectives and current content of the practical OWASP cheat sheet series of documents, which cover the most common web application security issues developers come across and who need accurate, and up-to-date information. The relatively concise cheat sheets are undergoing review, and three further cheat sheets (HTML 5, password storage and web services) are in progress. He also said the full set of cheat sheets are likely to be produced as a single book, as well as being freely accessible on the OWASP wiki (where all these are currently located and available). There was some useful feedback from the audience about the need for another tier of 1-2 page lists/summaries, and that all the cheat sheets should be formatted and structured in an indentical style where possible. Another delegate asked if all the details could be incorporated into the OWASP development guide. And as a last question, one person asked if issues relating to mutual authentication might be addressed.

I then described a different sort of strategy by OWASP, the OWASP Application Security Codes of Conduct project. I adopted these documents which were largely produced during the summit in Portugal earlier this year, to consolidate the work, produce release-quality documents and then promote their adoption. If you remember, these describe what OWASP believes other types of organization could do to support OWASP's mission. While these are aspirational (by OWASP), they do define some minimal normative behaviour, and optional additional recommendations, for government bodies, educational institutions, standards groups, trade organisations and certifying bodies. Excellent feedback from the audience included whether there was a need for prioritised approach for organisations that might fall into two target groups (e.g. educational institution and government body). The audience also asked about the specific requirements for educational institutions and the practicality of achieving them. I will revirew these ideas and post some suggestions to the project's mailing list.

Ryan Stinson provided an introduction to Common Attack Pattern Enumeration and Classification (CAPEC), and how this can be used to help target resources in an implementation agnostic through typical secure software development life cycles (SDLCs). This is easiest when threat modelling is used so that threats can be linked with attacks listed in CAPEC. It provides a way to cross-reference data from different points in the secure SDLC such as requirements, design, development, code review, QA, testing and operations. Switching to Common Weakness Enumeration (CWE), Ryan explained how this describes an overall style of a vulnerability and what challenges developers face relating to these. The taxonomy is extensive and fine-grained. Ryan uses this in his company to link vulnerabilities found during their engagements with the matching CWE issue. This provides additional centralised support resources and demonstrates the relevance to clients.

After a short break, I continued my pursuit of good threat modelling guidance and attended Mike Ware's session on this topic. He explained the need to keep threat modelling simple and described a process built around identifying who, what, where & how, combined with the impact and mitigations. The suggested process needs to involve a range of stakeholders which Mike referred to as the builders (e.g developers, suppliers), gluers (e.g. enterprise architects, CTO, shared service providers), owners (e.g. system, business, data), defenders (e.g. infrastructure, operations), and breakers (e.g. security teams, external penetration testers). The eight-part method includes diagramming the software architecture, enumerating the attack surface, documenting threats, illuminating assets, illuminating trust boundaries, and mitigation. A key take-away was that if you don't have good design information, don't attempt to begin threat modelling.

During lunch Moxie Marlinspike described the problems with trust using the internet, and in particular the difficulty of proving authenticity using SSL. His approachable presentation style won over the audience while he was discussing what might be called a complete failure in the current trust model that relieas on certificate authorities, domain name registrars and top level domain owners. He said that trust agility needs to have the ability for trust decisions to be reversed, and for users to be able to decide where they can place their trust. He described a previous concept called Perspectives but this had problems with completeness, privacy and responsiveness. Moxie went on to discuss his own inititiative called Convergence which could be a new authenticity system for SSL. It uses local caching and notary bounce to avoid the problems Perspectives had, and is designed with future extensibility buit in. There is a plugin for Firefox and this doesn't break the existing model — there is no need for changes on individual (web) servers. I need to check this out further.

After lunch I returned to the software assurance track to attend Adam Meyers' presentation on assessing threats to mobile computing. He described the milestones facilitating the current wave of mobile computing. He said that mobile security concerns relate to all the components (e.g. device, networks operating system, third party applications, browsers & web sites, enterprise applications), limitations (OS API, 3rd party application validation, carrier device authentication, data encryption, mandatory security controls, security updates). He described protections (and lack of) for data at rest, data in motion and voice for each operating system, and the additional personal security concerns, perimeter issues and data ownership concerns relating to mobile computing. Adam went on to explain detection and mitigation concerns due to issues like devices not always remianing on enterprise infrastructure, klack of real auditing for installed applications, difficulty in tracking user behaviour and difficulty in removing malicious code. He then identified the mobile computing attack surface and his most important recommendations for mobile software developers.

Continuing, Charles Schmidt described how to utilise Security Content Automation Protocol (SCAP). He said that even if you have an application with no flaws, no weaknesses and no bugs, it's still not secure. This is because deployment and operational management also matter. Perfect engineering makes an application securable, not secure. He said that documentation is a complete guide to an application, whereas guidance is a set of suggestions for how to configure it for specific use cases. The idea is that there can be automated security guidance, in a format that allows automated assessment of meeting these in the actual environment. This can provide the specific deviations to be identified that can then be assessed, and mitigated as necessary. SCAP is an open standard being used by the US government and others, for this automated guidance. The seven components are connected together by SCAP are:

• Common Configuration Enumeration (CCE) for configurable items in software
• Common Vulnerabilities and Exposures (CVE) for public vulnerabilities in public software
• Common Platform Enumeration (CPE) for identifying software & hardware items
• Common Vulnerability Scoring System (CVSS) to rank vulnerabilities on its likely danger
• Extensible Configuration Checklist Description Format (XCCDF) defining a standard format for security guidance that allow tailoring structures to customise recommendations and assessments
• Open Vulnerability Assessment Language (OVAL) format to express assertions about system state
• Open Checklist Interactive Language (OCIL) standard format for user questionnaires.

Apart from SCAP's well-known uses for vulnerability management, Charles described a use case for an off-the-shelf software package. The guidance for the application and the underlying infrastructure can be built using XCCDF, with OVAL for the low-lying technical checks and OCIL for the non-technical checks. If it is not a public application, CCE and CPE could be used for further annotation. The software acquirers can then use this for initial configuration and ongoing assessment. In another use case for inventory management, users can use the standardised format to be alerted about rogue installations and outdated versions.

For the final session of the day I returned to the OWASP track to listen to Ryan Barnett discussing how the ModSecurity Core Rule Set can be extended to implement some aspects of detection and response from AppSensor. After a brief introduction to the concepts, his dynamic presentation highlighted the pros and cons of building defense logic external to the application, and then how experimental rules have been created for the CRS for many detection points. There are some ideas there I will need to investigate, and make sure I write up for the next version of the AppSensor book.

The conference closed with a final recap by members of the board and the local organising committee. Vendors' prizes were distributed and thanks given to the volunteer organising team in Minneapolis. Yes, the whole week had been run fantastically well, and I hadn't heard any complaints. With over 540 delegates, that's excellent work. A high standard for Austin TX to follow next year.

The next global OWASP events are AppSec Latin America October 4th-7th in Porto Alegre, Brazil, and AppSec Asia November 8th-11th in Beijing, China. The next European AppSec conference will be held in Athens during July 2012.

All presentations will be available on the OWASP AppSec USA web page.